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Abstract 


Model  checking  is  a  well  known  formal  verification  technique  that  has  been  particu¬ 
larly  successful  for  finite  state  systems  such  as  hardware  systems.  Model  checking  essen¬ 
tially  works  by  a  thorough  exploration  of  the  state  space  of  a  given  system.  As  such,  model 
checking  is  not  directly  applicable  to  systems  with  unbounded  state  spaces  like  parameter¬ 
ized  systems.  The  standard  approach  for  applying  model  checking  to  unbounded  systems 
is  to  extract  finite  state  models  from  them  using  conservative  abstraction  techniques.  Prop¬ 
erties  of  interest  can  then  be  verified  over  the  finite  abstract  models. 

In  this  thesis,  we  propose  a  novel  abstraction  technique  for  model  checking  parameter¬ 
ized  systems  .  Parameterized  systems  are  systems  with  replicated  processes  in  which  the 
number  of  processes  is  a  parameter.  This  kind  of  replicated  structure  is  quite  common  in 
practice.  Standard  examples  of  systems  with  replicated  processes  are  cache  coherence  pro¬ 
tocols,  mutual  exclusion  protocols,  and  controllers  on  automobiles.  As  the  exact  number 
of  processes  is  a  parameter,  the  system  is  essentially  an  unbounded  system.  The  abstrac¬ 
tion  technique  we  propose,  called  environment  abstraction ,  tries  to  simulate  the  way  a 
human  designer  thinks  about  systems  with  replicated  processes.  The  abstract  models  we 
construct  are  easy  to  compute  and  powerful  enough  to  verify  properties  of  interest  without 
giving  any  spurious  counterexamples.  We  have  applied  this  abstraction  method  to  several 
well  known  parameterized  systems  like  cache  coherence  protocols  and  mutual  exclusion 
protocols  to  demonstrate  its  efficacy.  Importantly,  we  show  how  to  remove  a  commonly 
used,  but  severely  restricting  assumption,  called  the  atomicity  assumption,  while  verifying 
parameterized  systems. 

We  also  apply  insights  from  environment  abstraction  in  a  slightly  different  setting, 
namely,  that  of  systems  consisting  of  identical  processes  placed  on  a  network  graph. 
Adapting  principles  from  environment  abstraction,  we  show  how  the  verification  of  a  sys¬ 
tem  with  a  large  network  graph  can  be  decomposed  into  verification  of  a  collection  of 
systems,  each  with  a  small  constant  sized  network  graph.  As  far  as  we  are  aware,  ours  is 
the  first  result  to  show  that  verification  of  systems  with  complex  network  graphs  can  be 
decomposed  into  smaller  problems. 
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Chapter  1 


Introduction 


1.1  Introduction 


Modern  hardware  and  software  systems  are  extremely  large  and  intricate.  Designing 
such  systems  is  necessarily  an  error  prone  process  because  of  their  complexity.  A  sig¬ 
nificant  percentage  of  development  time  is  taken  up  in  identifying  bugs.  Error  finding  is 
primarily  accomplished  through  informal/incomplete  techniques  like  testing  and  simula¬ 
tion.  These  techniques  are  incomplete  in  that  they  are  not  guaranteed  to  find  all  the  bugs  in 
the  system.  The  few  errors  that  escape  testing  and  simulation  can  still  undermine  a  system, 
leading  to  huge  financial  losses  (Intel  Floating  point  error  [79])  or  even  potentially  fatal 
consequences  (the  Ariane  5  disaster  [50])  . 

Formal  verification  techniques  like  model  checking  and  theorem  proving  provide  an 
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alternative  to  incomplete  techniques.  These  techniques  explore  every  possible  behavior  of 
a  system  model  and  thus  find  all  the  bugs  in  the  model.  While  formal  verification  methods 
tend  to  be  expensive  (both  time  wise  and  labor  wise),  they  are  worth  the  effort  put  in. 
The  SLAM  project  at  Microsoft  [4],  which  is  one  of  the  well  known  success  stories  of 
model  checking,  managed  to  exhaustively  verify,  against  a  set  of  properties,  the  device 
drivers  in  a  Windows  machine.  It  had  been  previously  observed  that  most  of  the  crashes  of 
Windows  systems  occurred  due  to  bugs  in  the  device  drivers  that  escaped  detection  using 
testing  and  simulation.  The  SLAM  project  succeeded  in  eliminating  many  of  the  subtle 
bugs  responsible  for  system  crashes  using  model  checking.  Thus,  the  latest  versions  of 
the  Windows  operating  systems  have  benefitted  significantly  from  this  project.  Model 
checking  has  been  even  more  successful  in  the  hardware  industry.  In  fact,  most  chip 
design  companies,  such  as  Intel  and  AMD,  have  dedicated  model  checking  teams  as  part 
of  the  development  process.  Spurred  on  by  successes  like  these  in  the  software  industry 
and  the  hardware  industry,  there  is  an  increasing  adoption  of  formal  verification  methods 
as  an  integral  part  of  system  development. 

The  central  question  in  formal  methods  is  the  following:  given  a  model  M.  and  a 
property  <I>.  does  the  property  <I>  hold  on  system  AT?  Formally  this  is  expressed  as: 

M  |=  $? 

Model  checking,  which  is  the  formal  verification  technique  considered  in  this  thesis,  works 
by  a  thorough  exploration  of  the  state  space  of  a  given  system.  The  system  Af  is  usually 
given  as  a  Kripke  Structure  and  the  property  $  is  expressed  in  a  temporal  logic.  Kripke 
structures  are  specified  by  tuples  of  the  form  (S,  I,  T,  L )  where 
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•  S'  is  a  finite  collection  of  states, 


•  I  is  the  set  of  initial  states, 

•  T  C  S  x  S  is  the  transition  relation, 

•  L  is  a  labelling  function  that  associates  every  state  in  S  with  a  finite  set  of  labels. 

Essentially,  a  Kripke  structure  is  a  non-deterministic  finite  state  transition  system.  Since 
we  are  interested  in  the  evolution  of  a  system,  we  need  the  notion  of  time  to  express 
properties  of  interest.  These  properties  are  expressed  in  temporal  logic,  usually  CTL  [30] 
or  LTL  [65].  Traditional  temporal  logics  are  interpreted  over  Kripke  structures. 

In  recent  years,  a  whole  range  of  powerful  model  checkers  have  been  developed  start¬ 
ing  with  Ken  McMillan’s  seminal  Binary  Decision  Diagram  (BDD)  based  model  checker 
SMV  [57].  BDD  based  model  checkers  represent  sets  of  states  in  a  symbolic  fashion.  The 
representation  of  sets  of  states  as  BDDs  is  usually  compact,  and  they  can  be  efficiently 
manipulated  using  the  standard  operations  on  BDDs  [16].  Explicit  state  model  checkers 
like  SPIN  [48],  on  the  other  hand,  represent  states  explicitly.  While  explicit  representa¬ 
tion  of  states  can  end  up  being  cumbersome  (especially  if  the  reachable  state  space  is  very 
large),  the  fact  that  we  can  examine  individual  states  in  detail  allows  for  clever  pruning 
of  the  search  space.  For  highly  parallel  systems,  techniques  like  symmetry  reduction  in 
conjunction  with  explicit  state  model  checkers  are  among  the  best  options,  time  and  space 
wise,  available  [27].  In  the  last  few  years,  the  advent  of  powerful  Boolean  satisfiability 
solvers  (or  SAT  solvers)  has  led  to  the  development  of  a  new  class  of  model  checkers. 
SAT  based  Bounded  Model  Checkers  [8],  which  convert  the  model  checking  question  into 
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a  SAT  problem,  are  extremely  fast  and  very  useful  in  finding  bugs  that  can  be  reached 
in  a  small  number  of  transitions  (called  shallow  bugs).  Interpolant  based  model  check¬ 
ers  [60]  and  proof  based  abstraction  [46;  59;  61]  too  make  use  of  fast  SAT  solvers,  and  are 
currently  the  fastest  for  a  wide  range  of  problems  1 . 

All  the  different  model  checkers  essentially  perform  a  thorough  exploration  of  the  state 
space.  As  such,  model  checking  cannot  be  applied  to  large  real  world  systems  directly. 
Successful  application  of  model  checking  to  complex  pieces  of  code  like  device  drivers 
depends  on  the  use  of  abstraction  methods.  An  abstraction  method  extracts  a  small  finite 
state  system.  A,  called  the  abstract  system,  from  a  given  large  or  infinite  concrete  system 
C.  The  abstract  system  is  usually  a  conservative  abstraction  of  the  concrete  system,  which 
means  every  behavior  seen  in  C  is  also  seen  in  A.  It  can  be  shown  that  if  a  universal 
property  -  a  property  that  talks  about  all  paths  of  a  system  -  holds  on  the  abstract  system 
then  it  will  also  hold  on  the  concrete  model  (see  [23]  for  the  results  that  form  the  basis  for 
abstraction).  Thus,  instead  of  model  checking  C  directly,  we  can  model  check  A  and  infer 
the  properties  satisfied  by  C. 

Creating  abstract  models  involves  balancing  two  conflicting  aims: 

•  Small  Abstract  Models.  The  abstract  model  has  to  be  small  enough  that  we  can 
model  check  it  efficiently. 

•  Precise  Abstract  Models.  The  smaller  the  abstract  system,  the  more  behaviors  it 
allows.  For  instance,  if  the  transition  relation  were  true  (that  is,  there  is  a  transition 

'To  decide  whether  At  |=  <f>  is  computationally  very  hard  and  it  is  unlikely  that  any  one  method  performs 
the  best  on  all  problems. 
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from  every  state  to  all  the  other  states),  the  abstract  model  would  be  the  smallest 
possible  one  and  would  allow  every  trace.  Abstract  systems  that  have  too  many 
extraneous  traces  lead  to  spurious  counter  examples  -  traces  that  violate  the  property 
but  do  not  appear  in  the  concrete  system.  Thus,  while  the  abstract  model  should  be 
small,  it  should  also  be  precise.  This  latter  condition  tends  to  make  the  abstract 
system  large. 

When  we  model  check  the  abstract  model,  there  are  two  possible  outcomes,  as  shown 
in  Figure  1.1: 


Figure  1.1:  Counter  example  guided  model  checking  loop. 


(i)  The  model  checker  returns  true,  that  is,  the  abstract  model  satisfies  the  universal 
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property  $.  In  this  case,  the  concrete  model  also  satisfies  the  property  $. 


(ii)  The  model  checker  returns  false,  that  is,  the  abstract  model  violates  the  universal 
property  $.  In  this  case,  we  can  check  if  the  counter  example  trace  is  a  real  counter 
example  or  a  spurious  counter  example.  If  the  trace  is  a  real  counter  example,  we 
have  a  valid  counter  example  to  $.  Otherwise,  we  cannot  say  whether  the  concrete 
system  satisfies  $  or  not.  In  such  a  scenario,  another  abstract  model,  more  refined 
than  the  previous  one,  is  built  and  model  checked.  This  process  is  continued  until  a 
definitive  result  is  reached  or  the  system  capacity  is  exceeded. 

In  practice,  it  is  never  sufficient  to  build  just  one  abstract  model.  It  usually  takes 
several  abstract  models  -  each  more  precise  than  the  previous  one  -  to  reach  a  result. 
Since  the  question  of  whether  a  (possibly  infinite)  system  satisfies  a  temporal  property  <f> 
is  undecidable  in  general,  the  abstraction  refinement  loop  is  not  guaranteed  to  terminate. 

To  extract  useful  abstract  models,  the  abstraction  technique  must  be  domain  specific. 
This  is  because  the  class  of  systems  is  too  rich,  including  sequential  software,  concurrent 
protocols,  and  time  triggered  systems.  The  commonalities  between  these  classes  are  not 
yet  sufficiently  understood  that  we  can  devise  a  general  abstraction  mechanism.  All  no¬ 
table  successes  of  model  checking  (in  fact,  of  formal  verification  in  general)  have  come 
from  projects  which  have  focused  on  a  specific  class  of  systems,  for  instance,  the  class  of 
device  drivers  in  the  SLAM  project.  Following  this  trend,  this  thesis  proposes  a  new  ab¬ 
straction  technique  for  concurrent  systems  that  have  replicated  components  such  as  cache 
coherence  protocols  and  mutual  exclusion  protocols.  We  have  applied  this  abstraction 
technique  to  various  real  world  examples  to  demonstrate  its  efficacy. 
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1.1.1  Systems  with  Replicated  Processes 


Many  real  world  systems  consist  of  concurrently  executing  replicated  components.  Classic 
examples  of  such  systems  are  cache  coherence  protocols  which  consist  of  several  processes 
(local  caches)  executing  the  exact  same  cache  coherence  protocol.  That  is,  the  same  proto¬ 
col  is  replicated  at  several  different  processes.  As  another  example,  consider  controllers  in 
an  automobile  that  are  connected  via  a  common  bus.  The  controllers  themselves  might  be 
different  with  each  controller  performing  a  different  function.  All  controllers  use  some  set 
of  rules,  i.e.,  a  protocol  to  access  the  bus  in  a  safe  and  coordinated  manner.  This  bus  access 
protocol  must  be  the  same  in  all  the  controllers.  Thus,  if  we  consider  the  sub-system  con¬ 
sisting  of  the  bus  access  protocol,  we  again  have  an  instance  of  the  replicated  structure. 
Replication  is  a  widely  occuring  feature  in  real  systems.  In  fact,  any  scenario  in  which 
a  collection  of  processes  are  contending  for  a  common  resource  will  necessarily  involve 
replication  (of  protocols/algorithms). 

The  main  classes  of  replicated  systems  that  researchers  in  formal  verification  have 
considered  are  cache  coherence  protocols,  mutual  exclusion  protocols,  and  time  triggered 
protocols.  Such  protocols  are  crucial  parts  of  modern  computer  systems.  Systems  with 
replicated  components/processes  are  usually  designed  to  be  correct  no  matter  what  the  ex¬ 
act  number  of  processes  is.  Systems  with  replicated  components  that  have  a  parameterized 
number  of  processes  are  called  parameterized  systems.  In  general,  systems  can  be  param¬ 
eterized  not  just  by  the  number  of  processes  but  also  by  other  parameters  such  as  the  size 
of  the  buffers  available  per  communication  channel,  the  width  of  the  data  path,  and  so  on. 
All  parameterized  systems  are  essentially  unbounded  systems. 
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Applying  model  checking  to  such  parameterized  systems  is  challenging  because  they 
lack  fixed  state  spaces.  One  way  to  formally  reason  about  a  parameterized  system  is 
to  use  model  checking.  In  this  approach,  a  finite  state,  conservative  abstraction  of  the 
system  is  extracted  and  model  checked.  This  is  the  approach  followed  by  Pnueli  et  al.  [66], 
Lahiri  et  al.  [52;  53],  Delzanno  et  al.  [28;  29],  Chou  et  al.  [21],  German  and  Sistla  [43], 
Namjoshi  [36],  and  Kahlon  et  al.  [35].  The  abstraction  created  is  a  conservative  (or  sound) 
abstraction.  This  means  any  universal  property  (a  property  that  talks  about  all  paths) 
that  holds  on  the  abstract  model  will  also  hold  on  the  concrete  model.  The  implication 
in  the  other  direction  does  not  usually  hold,  that  is,  if  the  universal  property  holds  on 
the  parameterized  system  then  it  may  or  may  not  hold  on  an  abstract  model.  There  are 
other  model  checking  based  techniques  like  Invisible  Invariants  [52;  53]  and  McMillan’s 
Compositional  Reasoning  [62]  which  use  model  checking  in  a  different  fashion. 

An  alternate  approach  to  verifying  parameterized  systems  is  to  use  theorem  prov- 
ing(We  classify  any  technique  that  requires  the  users  to  supply  lemmas  about  the  system 
as  theorem  proving.).  McMillan’s  Compositional  Reasoning,  mentioned  earlier,  is  a  good 
example  in  this  class  (model  checking  is  used  in  this  approach  but  the  user  has  to  come 
up  with  non  trivial  lemmas).  Rushby  et  al.  have  used  the  PVS  theorem  prover  to  estab¬ 
lish  properties  of  certain  clock  synchronization  algorithms  (used  in  automobiles)  and  other 
systems  with  a  parameterized  number  of  replicated  processes,  see  [49;  69]. 

One  of  the  main  contributions  of  this  thesis  is  an  abstraction  technique,  named  envi¬ 
ronment  abstraction ,  developed  for  reasoning  about  parameterized  systems.  Environment 
abstraction  exploits  the  replicated  structure  of  a  parameterized  system  to  make  its  verifi¬ 
cation  easy.  Ideas  from  this  abstraction  can  be  used  even  if  the  number  of  replicated  pro- 
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cesses  in  a  system  is  fixed.  The  essential  principle  is  to  create  an  abstraction  that  matches 
human  reasoning  closely.  When  a  human  designer  creates  a  system  with  replicated  pro¬ 
cesses,  (s)he  reasons  about  its  correctness  by  focussing  on  the  execution  of  one  reference 
process  and  sees  how  the  other  processes  might  interfere  with  its  execution.  Following 
this  idea,  our  abstraction  maintains  detailed  information  on  the  reference  process  and  ab¬ 
stracts  the  other  processes  in  relation  to  the  reference  process.  The  resulting  abstraction 
is  quite  powerful  and  we  believe  it  is  the  most  natural  abstraction  (that  is,  it  corresponds 
most  closely  to  the  abstraction  humans  use  in  reasoning  about  parameterized  systems). 

In  the  tradition  of  classical  model  checking,  our  approach  provides  an  automated  tool 
chain  (shown  in  Figure  1.2). 


Protocol 

Description 


Env.  abst. 

■=: > 


Abstract 

model 


* 


SMV 

Model  Checker 


Figure  1.2:  Tool  chain  for  environment  abstraction. 
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1.  The  behavior  of  the  distributed  algorithm/protocol  is  described  in  a  suitable  input 
language,  cf.  Section  3.3  and  Section  4.2. 

The  user’s  role  ends  with  inputting  the  protocol  to  the  verification  tool. 

1.  The  environment  abstraction  tool  extracts  a  finite  state  model  from  the  protocol  de¬ 
scription,  and  puts  the  model  in  SMV  format. 

2.  SMV  verifies  the  specified  properties. 

We  have  used  this  abstraction  based  method  to  prove  properties  of  well  known  cache 
coherence  systems,  mutual  exclusion  algorithms,  and  real  time  protocols. 

Typically,  handling  liveness  properties  is  much  harder  (theoretically)  than  handling 
safety  properties.  For  instance,  the  Invisible  Invariants  method  [64]  requires  significant  ad¬ 
ditional  work  before  it  can  handle  liveness  properties  and  the  Indexed  Predicates  method  [52; 
53]  cannot  handle  liveness  properties  at  all.  Informally,  this  is  because  verification  of 
safety  properties  depends  only  on  the  reachable  set  of  states,  whereas  verification  of  live¬ 
ness  properties  depends  also  on  the  order  in  which  the  various  states  are  reached.  Ranking 
functions  are  needed  to  argue  that  desirable  states  are  eventually  reached.  Finding  such 
ranking  functions  is  typically  a  non-trivial  task. 

In  contrast,  extending  our  method  to  handle  liveness  is  very  simple.  Since  our  abstract 
model  simulates  the  execution  of  one  single  process  in  precise  detail  and  consequently, 
liveness  properties  of  a  single  process  are  easy  to  reason  about.  We  only  need  to  rule  out 
spurious  loops  introduced  by  the  abstraction. 
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Importantly,  other  model  checking  based  approaches  to  parameterized  verification 
make  the  atomicity  assumption  while  handling  parameterized  protocols.  The  atomicity 
assumption  in  essence  states  that,  in  a  distributed  system  with  several  components,  any 
component  can  know  (or  rather  read)  the  state  of  all  the  other  components  instantaneously. 
This  is  quite  unrealistic  and  simplifies  a  distributed  protocol  significantly.  In  this  thesis, 
we  describe  a  simple  extension  to  remove  the  atomicity  assumption.  Note  that  the  term 
atomicity  is  used  in  a  different  sense  from  the  classical  usage  in  distributed  computing  lit¬ 
erature.  In  the  latter  usage,  atomicity  is  used  to  qualify  a  single  read  or  write  operation.  An 
atomic  read  or  write  operation  is  one  which  happens  in  an  atomic  time  unit  and  thus,  no 
other  operation  can  interfere  with  its  execution.  Atomicity,  as  used  in  this  thesis,  qualifies 
a  set  of  read/write  operations. 

The  idea  of  looking  at  a  system  from  the  point  of  view  of  a  reference  process  can  be 
carried  over  into  other  settings  as  well.  We  consider  systems  with  replicated  processes 
which  are  arranged  at  the  nodes  of  an  underlying  network  graph.  The  processes  commu¬ 
nicate  by  passing  tokens  among  themselves.  If  we  are  interested  in  checking  two-process 
properties  of  such  a  system,  we  can  show  that  it  is  enough  to  consider  how  the  system 
looks  from  the  point  of  view  of  pairs  of  processes.  This  result  lets  us  decompose  the  ver¬ 
ification  problem  of  a  system  with  a  large  network  graph  into  verification  of  a  collection 
of  systems  with  small,  constant  sized  network  graphs.  This  network  decomposition  result 
lays  the  ground  for  reasoning  about  systems  with  network  graphs  and  richer  inter-process 
communication  (such  as  complex  leader  election  protocols). 
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1.1.2  Thesis  Outline 


The  outline  for  the  rest  of  the  thesis  is  as  follows.  In  the  next  chapter  we  present  environ¬ 
ment  abstraction  in  general  terms  and  derive  its  mathematical  properties.  We  show  that 
environment  abstraction  is  sound  for  indexed  temporal  logic  specifications  in  a  very  gen¬ 
eral  framework,  and  discuss  the  relationship  of  our  method  to  counter  abstraction,  canon¬ 
ical  abstraction,  and  predicate  abstraction.  This  chapter  lays  the  foundation  for  our  work 
on  verification  of  parameterized  systems  with  replicated  processes.  The  same  chapter  also 
describes  extensions  to  environment  abstraction  and  considers  some  of  the  issues  involved 
in  applying  this  abstraction  method  to  practical  systems. 

State-of-the-art  architectures  crucially  rely  on  cache  coherence  protocols  for  increased 
performance.  These  protocols  are  extremely  intricate  and,  usually,  several  processors  run 
these  protocols  concurrently.  Thus,  ensuring  the  correctness  of  such  protocols  is  a  chal¬ 
lenging  problem  and  formal  verification  techniques  are  indispensable.  Since  the  number 
of  processors  executing  the  cache  protocol  can  vary,  cache  coherence  verification  is  a  clas¬ 
sical  example  of  the  parameterized  verification  problem.  In  Chapter  3,  we  show  how  to 
apply  environment  abstraction  for  verifying  cache  coherence  protocols.  We  first  propose 
a  simple  programming  language  that  allows  us  to  model  cache  protocols  at  an  algorithmic 
level.  We  then  describe  the  precise  abstract  state  space  used  in  abstracting  cache  protocols. 
Environment  abstraction  as  presented  in  Chapter  2  talks  only  about  the  general  structure 
of  the  abstract  state  space.  The  precise  form  of  the  abstract  states  depends  on  the  class  of 
systems  under  consideration.  Chapter  3  also  deals  with  the  crucial  issue  of  how  exactly 
we  compute  the  abstract  model.  We  have  applied  this  method  to  verify  safety  properties  of 
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several  cache  coherence  protocols,  including  several  variants  of  German’s  protocol  and 
a  modified  version  of  the  Flash  protocol.  The  language  constructs  used  in  describing 
cache  coherence  protocols  are  quite  simple  so  that  the  essential  principle  behind  the  com¬ 
putation  of  the  abstract  model  is  easy  to  understand.  It  is  for  this  reason  that  we  consider 
cache  coherence  protocols  as  the  first  example. 

In  Chapter  4,  we  show  how  environment  abstraction  can  be  applied  to  mutual  ex¬ 
clusion  protocols,  which  exhibit  complex  inter-process  communication.  As  with  cache 
coherence  protocols,  we  first  describe  a  simple  programming  language  that  allows  us  to 
describe  mutual  exclusion  protocols  at  an  algorithmic  level.  The  precise  form  of  the  ab¬ 
stract  states  is  then  described,  followed  by  a  section  on  how  to  compute  the  abstract  model. 
We  demonstrate  the  power  of  our  approach  by  verifying  Lamport’s  Bakery  algorithm  and 
Szymanski’s  mutual  exclusion  protocol.  Note  that  in  Chapter  4,  we  verify  mutual  exclu¬ 
sion  protocols  under  the  atomicity  assumption. 

In  Chapter  5,  we  show  how  to  verify  mutual  exclusion  protocols  without  the  atomicity 
assumption.  The  atomicity  assumption,  which  says  that  any  component  can  know  the 
state  of  all  the  other  components  instantaneously,  significantly  reduces  the  complexity  of  a 
protocol.  To  handle  protocols  in  full  generality,  without  the  atomicity  assumption,  we  need 
to  keep  track  of  history  information.  We  introduce  monitor  processes  for  this  purpose  and 
show  how  we  can  apply  environment  abstraction  in  presence  of  these  monitor  processes. 

In  Chapter  6,  we  consider  a  different  system  model,  namely  systems  built  around  net¬ 
work  graphs.  For  example,  in  routing  protocols,  the  underlying  topology  of  the  system 
plays  a  crucial  role.  Similarly,  in  many  wireless  applications,  the  system  performance  de- 


13 


pends  on  how  the  different  wireless  entities  are  connected.  Formal  verification  research 
has  only  now  begun  to  address  the  problem  of  verifying  these  systems  with  complex  net¬ 
work  graphs.  As  a  first  step  towards  this  larger  problem,  we  consider  systems  consisting 
of  a  collection  of  identical  processes  arranged  on  the  nodes  of  a  network  graph  with  very 
limited  communication  between  the  processes.  We  describe  a  new  method  to  verify  such 
networks  of  homogeneous  processes  that  communicate  by  token  passing.  Given  an  arbi¬ 
trary  network  graph  and  an  indexed  LTL  \  X  property,  we  show  how  to  decompose  the 
network  graph  into  multiple  constant  size  networks,  thereby  reducing  one  model  checking 
call  on  a  large  network  to  several  calls  on  small  networks.  We  thus  obtain  cut-offs  for 
arbitrary  classes  of  networks,  adding  to  previous  work  by  Emerson  and  Namjoshi  on  the 
ring  topology  [37].  Our  results  on  LTL  \  X  are  complemented  by  a  negative  result  that 
precludes  the  existence  of  reductions  for  CTL  \  X  on  general  networks. 

The  last  chapter  concludes  this  thesis  with  a  summary  of  contributions  and  possible 
extensions  to  the  work  presented  here.  We  also  discuss  some  of  the  outstanding  challenges 
in  parameterized  verification. 
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Chapter  2 


Environment  Abstraction 


2.1  Introduction 


When  a  human  engineer  designs  a  hardware  or  software  system,  the  correctness  of  the 
system,  naturally,  is  among  the  main  concerns  of  the  designer.  Although  the  reasoning 
of  the  designer  is  usually  not  available  to  the  verification  engineer  in  terms  of  assertions 
or  proofs,  the  reasons  for  correctness  are  often  reflected  in  the  way  a  program  is  written. 
Knowledge  of  these  implicit  design  principles  can  be  systematically  exploited  for  the  con¬ 
struction  of  abstract  models.  For  example,  it  is  natural  for  us  to  assume  that  control  flow 
conditions  yield  important  predicates  for  reasoning  about  software,  and  that  polygons  are 
good  approximations  of  numeric  data  that  are  human  generated.  Thus,  the  presence  of 
a  human  engineer  renders  the  analysis  of  hardware  and  software  very  different  from  the 
analysis  of  systems  in  physics,  chemistry,  or  biology. 
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To  pinpoint  this  difference,  consider  an  example  frequently  discussed  in  the  history  of 
science,  namely  the  Ptolemaic  system  in  which  the  planet  earth  is  surrounded  by  the  sun. 
The  persistance  of  Ptolemy’s  viewpoint  over  many  centuries  shows  the  intuitive  reasoning 
which  the  human  mind  applies  to  complex  systems:  we  tend  to  imagine  systems  with  the 
human  observer  in  the  center.  While  a  Ptolemaic  viewpoint  is  known  to  be  wrong  (or, 
more  precisely,  infeasible)  in  physics,  it  naturally  appears  in  the  systems  we  construct. 
Consequently,  the  Ptolemaic  viewpoint  yields  a  natural  abstraction  principle  for  computer 
systems. 

In  this  chapter,  we  explore  a  Ptolemaic  viewpoint  of  concurrent  systems  to  devise 
an  abstraction  method  for  concurrent  systems  with  replicated  processes  which  we  call 
environment  abstraction.  Our  systems  are  parameterized,  i.e.,  the  number  of  processes 
is  a  parameter,  and  all  processes  execute  the  same  program.  We  write  V(K)  to  denote  a 
system  with  K  processes  1 .  We  argue  that  during  the  construction  of  such  a  system,  the 
programmer  naturally  imagines  him/herself  to  be  in  the  position  of  one  reference  process, 
around  which  the  other  processes  -  which  constitute  the  environment  -  evolve.  Thus,  in 
many  cases,  an  abstract  model  that  describes  the  system  from  the  viewpoint  of  a  reference 
process  contains  sufficient  information  to  reason  about  specifications  of  interest. 

The  goal  of  environment  abstraction  is  to  put  this  intuition  into  a  formal  framework.  In 
environment  abstraction,  an  abstract  state  is  a  description  of  a  concrete  system  state  from 
the  point  of  view  of  a  single  reference  process  and  its  environment.  The  properties  of  the 
reference  process  are  computed  as  if  the  process  were  chosen  without  loss  of  generality. 
Thus,  verification  results  about  the  reference  process  generalize  to  all  processes  in  the 

1  We  will  later  also  consider  a  finite  number  of  non-replicated  processes  in  addition. 
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system. 


From  a  practical  perspective,  environment  abstraction  shares  many  properties  with 
predicate  abstraction  as  used  in  SLAM  [4],  BLAST  [47],  and  MAGIC  [19]: 


•  Environment  abstraction  computes  a  finite-state  abstract  model  on  which  a  stan¬ 
dard  model  checker  can  verify  a  property.  To  verify  an  indexed  temporal  property 
\/x.(p(x)  on  all  parameterized  models  V(K),  K  >  1,  the  model  checker  just  needs 
to  verify  the  quantifier-free  property  fi(x)  on  a  single  abstract  model  VA  which 
interprets  the  variable  x.  The  model  VA  is  obtained  by  a  variation  of  existential 
abstraction  that  quantifies  over  the  parameter  K  and  the  index  variable  x. 


•  Instead  of  computing  the  precise  abstract  model,  environment  abstraction  over¬ 
approximates  the  abstract  model.  To  this  end,  each  statement  of  the  concurrent 
program  is  approximated  separately  using  decision  procedures.  Thus,  similar  to 
SLAM,  BLAST,  MAGIC,  the  abstract  model  used  in  the  verification  is  an  over¬ 
approximation  of  VA. 


The  aim  of  this  chapter  is  to  describe  environment  abstraction  from  first  principles. 
We  derive  environment  abstraction  from  a  few  simple  logical  principles,  and  show  its 
soundness  for  a  large  class  of  indexed  ACTL*  properties.  In  addition,  we  put  the  method 
in  perspective  to  other  abstraction  approaches  such  as  Indexed  Predicates,  and  TVLA’s 
Canonical  Abstraction. 


17 


2.2  A  Generic  Framework  for  Environment  Abstraction 


We  consider  parameterized  concurrent  systems  V(K),  where  the  parameter  K  >  1  de¬ 
notes  the  number  of  replicated  processes.  The  processes  are  distinguished  by  unique  in¬ 
dices  in  {1, ,  K }  which  serve  as  process  ids.  Each  process  executes  the  same  program 
which  has  access  to  its  process  id.  We  do  not  make  any  specific  assumptions  about  the 
processes,  in  particular  we  do  not  require  them  to  be  finite  state  processes. 

Consider  a  system  V{K)  with  a  set  SK  of  states.  Each  state  s  G  SK  contains  the  whole 
state  information  for  each  of  the  K  concurrent  processes,  i.e.,  s  is  a  vector 

(si, . . . ,  sK) 

Technically,  V(K)  is  a  Kripke  structure  (Sk,  Ik,  Rk,  Lr )  where  Ik  is  the  set  of  initial 
states  and  RK  is  the  transition  relation.  We  will  discuss  the  labeling  L  K  for  the  states  in 
Sk  below. 

Remark  1.  While  we  consider  systems  composed  solely  of  replicated  processes,  sys¬ 
tems  with  a  constant  number  of  non-replicated  processes,  in  addition  to  a  set  of  replicated 
processes,  can  also  be  similarly  handled.  For  such  systems,  each  state  is  of  the  form 
(si, . . . ,  sk,  t )  where  t  is  the  combined  state  of  all  non-replicated  components.  With  this 
minor  change,  the  treatment  presented  below  can  be  carried  as  is  to  this  modified  setting 
as  well. 

Process  Properties.  We  will  describe  properties  of  V(K)  using  formulas  with  one  free 
index  variable  x  which  denotes  the  index  of  a  process.  We  will  call  such  formulas  process 
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properties ,  as  they  may  or  may  not  hold  true  for  a  process  in  a  given  state.  For  a  process 
property  (j>(x),  we  write 

«  1=  0(c) 

to  express  that  in  state  s,  process  c  has  property  0.  We  assume  that  for  each  state  s  and 
process  c,  we  have  either  s  \=  0(c)  or  s  |=  “'0(c). 

Example  2.2.1.  The  following  statements  are  sample  process  properties: 

•  “Process  x  has  program  counter  position  5.” 

We  will  express  this  fact  by  the  formula  pc  [re]  =  5.  We  may  use  this  process  property 
in  all  systems  where  the  processes  have  a  variable  pc. 

•  “There  exists  a  process  y  f  x  where  p c[y]  =  5.” 

This  property  is  expressed  by  the  quantified  formula  3 y  f  x.pc  [y\  =  5.  Note  that  in 
this  formula,  only  variable  x  is  free.  Intuitively,  this  property  means  that  a  process 
in  the  environment  of  x  has  program  counter  position  5.  We  shall  therefore  write 
5  G  env(x)  to  express  this  property. 

•  “Process  x  has  program  counter  position  5,  and  there  exist  two  other  processes 
t\  and  t-2  in  program  counter  position  1  such  that  the  data  variable  d  satisfies 

d[x]  <  d[tf  =  d[t2\.” 

This  property,  too,  can  be  expressed  easily  with  two  quantifiers  and  one  free  variable 
x  as  shown  below 

3ti,  t2.  txft2Axf  {ti,  t2}  A  pc[x]  =  5  A  p c[ti\  =  1 
Apc[f2]  =  1  A  d[x]  <  d[ti\  A  d[ti\  =  d[t2] 
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Note  that  the  labels  discussed  in  the  first  two  items  are  highly  relevant  in  our  applica¬ 
tions  and  will  be  discussed  below  in  detail. 

Labels  and  Descriptions.  In  environment  abstraction,  we  distinguish  two  sets  of  process 
properties  that  we  use  for  different  purposes: 

(a)  Labels.  A  label  is  a  process  property  l(x)  that  we  use  in  a  specification.  The  set 
of  all  labels  is  denoted  by  L.  For  example,  for  l(x)  =  (pc[x]  =  10),  we  may  write 
Vx.  AG  -<(pc[x]  =  10)  to  denote  that  no  process  reaches  program  counter  10.  For  a 
process  c,  a  c-label  is  an  instantiated  formula  1(c)  where  l(x)  G  L.  We  write  L(c )  to 
denote  the  set  of  c-labels. 

In  the  Kripke  structure  V(K),  a  state  s  has  a  label  1(c),  if  s  |=  1(c),  i.e., 

Lk(s)  =  {1(c)  :  s  \=  1(c),  ce  [1  ..K]}. 

(b)  Descriptions.  A  description  is  a  process  property  A(x)  which  typically  describes 
not  only  the  process,  but  also  its  environment,  as  in  the  second  and  the  third  items 
of  Example  2.2.1.  The  set  of  all  descriptions  D  is  our  abstract  state  space. 

Intuitively,  an  abstract  state  A(x)  G  D  is  an  abstraction  of  a  concrete  state  s  if  there 
exists  a  concrete  process  c  which  has  property  A,  i.e.,  if  s  |=  A(c).  For  example, 
the  description  pc[x]  =  5  represents  all  states  s  which  have  a  process  c  whose  pc 
variable  equals  5.  In  our  applications,  the  descriptions  will  usually  be  relatively 
large  and  intricate  formulas. 

Remark  2.  Note  that  our  process  properties  contain  a  free  index  variable  x.  While  the 
name  of  the  free  index  variable  is  immaterial,  we  have  chosen  to  call  it  x  as  it  makes  the 
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presentation  less  cluttered.  We  also  use  x  in  other  places,  for  example,  in  single  index 
formulas  Vx.$(x).  The  usage  should  be  clear  from  the  context. 

Soundness  Requirements  for  Labels  and  Descriptions.  We  will  need  two  require¬ 
ments  on  the  set  D  of  descriptions  and  the  set  L  of  labels  to  make  them  useful  as  building 
blocks  for  the  abstract  model: 

1.  Coverage.  For  each  system  V(K),K  >  2,  each  state  s  in  SK  and  each  process  c 
there  is  some  description  A  (x)  &  D  which  describes  the  properties  of  c,  i.e., 

s  |=  A(c). 

The  coverage  property  means  that  every  concrete  situation  is  reflected  by  some  ab¬ 
stract  state. 

2.  Congruence.  For  each  description  A(A)  G  D  and  each  label  l{x)  G  L  it  holds  that 
either 

A(x)  — » l(x) 

or 

A  (A)  — ■>  -i l(x). 

In  other  words,  the  descriptions  in  D  contain  enough  information  about  a  process  to 
conclude  whether  a  label  holds  true  for  this  process  or  not. 

The  congruence  property  enables  us  to  give  natural  labels  to  each  state  of  the  abstract 
system:  An  abstract  state  A  (a;)  has  the  label  l(x)  if  A  (A)  — *  /(A). 
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2.2.1  Description  of  the  Abstract  System  VA. 


Given  two  sets  D  and  L  of  descriptions  and  labels  that  satisfy  the  coverage  and  congru¬ 
ence  criteria,  the  abstract  system  VA  is  a  Kripke  structure 

(D,  IA,  RA,  La) 

where  each  A(a;)  e  D  has  a  label  l(x)  G  L  if  A(x)  — >  l{x),  i.e.,  LA(A(x))  =  {l(x)  : 
A(x)  —>  /(c)}.  Before  we  describe  IA  and  /?  ',  we  can  already  state  the  following  lemma 
about  preservation  of  labels. 

Lemma  2.2.2.  Suppose  that  s  |=  A(c).  Then  the  following  are  equivalent: 

(i)  The  concrete  state  s  has  label  1(c). 

(ii)  The  abstract  state  A(x)  has  label  l(x). 

Proof.  Assume  that  (i)  but  not  (ii).  Then  by  the  congruence  property,  we  have  A(x)  — ■> 
-i l(x).  Together  with  the  assumption  s  |=  A(c)  of  the  lemma,  we  conclude  that  s  |=  — 'Z(c), 
which  contradicts  (i).  The  converse  implication  is  trivial. 

Note  that  the  proof  of  the  lemma  requires  the  congruence  property.  □ 

This  motivates  the  following  abstraction  function: 

Definition  2.2.3.  Given  a  concrete  state  s  and  a  process  c,  the  abstraction  of  s  with  refer¬ 
ence  process  c  is  given  by  the  set 

ccc(s)  =  (A(a:)  E  D  :  s  \=  A(c)}. 
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Note  the  following  remarks  on  this  definition: 


•  The  coverage  requirement  guarantees  that  ac(s)  is  always  non-empty. 

•  If  the  A(x)  are  mutually  exclusive,  then  ac(s)  always  contains  exactly  one  descrip¬ 
tion  A(x). 

•  Two  processes  c  and  d  of  the  same  state  s  will  in  general  give  rise  to  different  ab¬ 
stractions,  i.e.,  ac(s)  =  a<i(s)  is  in  general  not  true. 

Remark  3.  In  our  application  of  environment  abstraction  to  various  distributed  protocols, 
it  is  usually  the  case  that  the  abstract  descriptions  A(x)’s  are  mutually  exclusive.  Thus, 
given  a  state  s  and  reference  process  c,  ac($)  will  contain  exactly  one  abstract  description 
A(x).  In  such  cases,  we  simply  write  ac(s)  =  A(x). 

Now  we  define  the  transition  relation  of  the  abstract  system  by  a  variation  of  existential 
abstraction:  RA  contains  a  transition  between  A|  (x)  and  A2(x)  if  there  exists  a  concrete 
system  V(K),  two  states  si,  s2  and  a  process  r  such  that 

1.  Ai(A)  G  ar(si), 

2.  A2(x)  G  o;r(s2),  and 

3.  there  is  a  transition  from  s i  to  s2  in  V(K),  i.e.,  (si,  s2)  G  Rk- 

We  note  three  important  properties  of  this  definition: 

•  We  existentially  quantify  over  K,  s i,  s2,  and  r.  This  is  different  from  standard 
existential  abstraction  where  we  only  quantify  over  si  and  s2.  For  fixed  K  and  r, 
our  definition  is  equivalent  to  existential  abstraction. 
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•  Both  abstractions  Ai  and  A2  use  the  same  process  r.  Thus,  the  point  of  view  of  the 
abstraction  is  not  changed  in  the  transition. 

•  The  process  that  actually  makes  the  transition  can  be  any  process  in  V(K),  it  does 
not  have  to  be  r. 

Finally,  the  set  IA  of  abstract  initial  states  is  the  union  of  the  abstractions  of  concrete 
states,  i.e.,  A  (re)  G  IA  if  there  exists  a  system  V(K)  with  state  s  G  Ik  and  process  r  such 

that  A  (a;)  G  av(s). 

To  summarize,  VA  is  a  Kripke  structure  (D,  IA ,  RA,  LA)  such  that  the  set  of  abstract 
descriptions  D  satisfies  the  congruence  and  closure  conditions  with  respect  to  the  set  of 
labels  L  and  the  transition  relation  llA  is  defined  in  an  existential  fashion. 

Remark  4.  It  will  be  convenient  later  on  to  represent  the  abstract  descriptions  as  tuples. 
For  example,  if  the  abstract  descriptions  were  all  of  the  form 

±Pi(x)  A  . . .  ±  T  >  1 

where  Pi(x), . . . ,  Pt(x)  are  some  process  properties  and  ±P,(x)  indicates  that  property 
Pi(x)  can  appear  negated  or  unnegated,  then  we  can  represent  an  abstract  description  A(x) 
as  a  tuple 

where  pf  =  1  AA  A(x)  Pt(x).  That  is,  the  value  of  each  bit  pt  reflects  the  polarity  of 
the  corresponding  predicate  Pl(x)  in  A(x). 
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Single-Indexed  Specifications  and  Soundness  of  Environment  Abstraction.  We  con¬ 
sider  an  indexed  temporal  specification  language  where  specifications  have  the  form 

\/x.<f>(x). 

Here,  f(x)  is  an  ACTL*  formula  whose  atomic  formulas  are  labels  in  L.  We  say  that 
V(K)  |=  \/x.(f>(x)  if  for  all  c  G  {1 . . .  A'}  we  have  V(K)  |=  0(c). 

Despite  the  single  index,  this  specification  language  is  powerful,  because  the  labels  in 
L  can  talk  about  other  processes.  For  example,  using  the  label  5  G  env(x)  from  Exam¬ 
ple  2.2.1  above,  we  can  express  mutual  exclusion  by  the  formula 

Vic.AG  (pc[x]  =  5)  — ■>  -i(5  G  env(x)) 

as  well  as  many  other  properties.  For  a  more  thorough  discussion  of  the  expressive  power 
of  this  language,  see  Section  2.4.  In  Section  2.5.1  we  will  also  consider  abstractions  with 
multiple  reference  processes  for  specifications  with  multiple  indices. 

For  environment  abstractions  with  L  and  D  that  satisfy  coverage  and  congruence,  we 
have  the  following  general  soundness  theorem. 

Theorem  2.2.4  (Soundness  of  Environment  Abstraction).  Let  V(K)  be  a  parameter¬ 
ized  system  and  VA  be  its  abstraction  as  described  above.  Then  for  single  indexed  ACTL  * 
specifications  dx.oix)  the  following  holds: 

VA  |=  4>(x)  implies  VK.V(K)  |=  Vx.0(x). 
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2.3  Soundness 


We  will  now  give  a  proof  of  correctness  for  Theorem  2.2.4.  Before  we  give  the  proof 
of  the  soundness  theorem  we  introduce  some  notation  to  simplify  later  proofs. 

2.3.1  Simulation  Modulo  Renaming 

Given  a  fixed  process  c,  we  write  VC(K)  to  denote  the  Kripke  structure  obtained  from 
V(K )  where  LK  is  restricted  to  only  those  labels  which  refer  to  process  c.  Thus,  VC{K)  is 
labeled  only  with  c-labels. 

Fact  1.  Let  c  be  a  process  in  V(K)  and  f(x)  be  a  temporal  formula  over  atomic  labels 
from  L.  Then 

V(K)  [=  0(c)  if  and  only  if  VC(K )  (=  0(c). 

This  follows  directly  from  the  fact  that  the  truth  of  0(c)  depends  only  on  c-labels. 

Our  soundness  proofs  will  require  a  simple  variation  of  the  classical  abstraction  the¬ 
orem  [23].  Recall  that  the  classical  abstraction  theorem  for  ACTL*  says  that  for  ACTL* 
specifications  0  and  two  Kripke  structures  K\  and  K2  it  holds  that  I\\  A  K2  and  K\  \=  0 
together  imply  K2  \—  0.  That  is,  if  A\  simulates  K2  then  any  ACTL*  property  satisfied 
by  Ki  is  also  satisfied  by  I\  2. 

Definition  2.3.1  (Simulation  Modulo  Renaming).  Let  K  be  a  Kripke  structure,  and  c  and 
d  be  processes.  Then  K[c/d]  denotes  the  Kripke  structure  obtained  from  K  by  replacing 
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each  label  of  the  form  1(c)  by  1(d).  Simulation  modulo  renaming  A  c/a  is  defined  as  follows : 

K\  -<c/d  K-2  iff  K\  [c/ d]  f  K2. 

Then  f~c/d  gives  rise  to  a  simple  variation  of  the  classical  abstraction  theorem: 

Fact  2  (Abstraction  Theorem  Modulo  Renaming).  Let  4>(x)  be  a  temporal  formula  over 
atomic  labels  from  L,  and  let  K\ .  K2  be  Kripke  structures  which  are  labelled  only  with 
Ci-labels  and  c2-labels  respectively. 

If  K-2  —C2/C1  K\  and  Kx  |=  0(ci),  then  K2  |=  (f>(c2). 

Proof  First  note  that  K2  \=  f(c2)  is  equivalent  to  K2[c2/c\]  \=  <f>(ci):  if  the  labels  in  the 
Kripke  structure  and  the  atomic  propositions  in  the  specification  are  consistently  renamed, 
then  the  satisfaction  relation  does  not  change. 

Thus,  given  that  K2  ^C2/(;:|  K\  and  I\\  |=  4>(cf),  it  is  enough  to  show  that  iT2[c2/ci]  |= 
([)(c\ )  .  By  the  definition  of  ; <c/d ,  K2  ^(>2/Cl  I\\  iff  A'2[c2/ci]  A  K\  and  by  the  classi¬ 
cal  abstraction  theorem  [23],  K1  |=  (j)(cf)  implies  K2[c2/ci]  \=  f(ci).  This  proves  the 
abstraction  theorem.  □ 

2.3.2  Proof  of  Soundness 


We  will  show  that  environment  abstraction  preserves  indexed  properties  of  the  form 
Wx.(p(x)  where  f(x)  is  an  ACTL*  formula  over  atomic  labels  from  L. 

Step  1:  Reduction  to  Simulation.  Formally,  we  have  to  show  that 
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VA  \=  (f>(x)  implies  \/K.V(K)  \=\/x.(f>(x). 

By  the  semantics  of  our  specification  language,  this  is  equivalent  to  saying  that  for  all 

K  >  1, 

VA  |=  4>(x)  implies  Vc  £  [l..K\.V(K)  |=  0(c). 

Thus,  we  need  to  show  that  for  all  K  >  1  and  all  processes  c  £  [1  ..K] 

VA  f=  4>(x)  implies  V{K)  f=  0(c). 

Recall  that  VC(K)  is  the  Kripke  structure  obtained  from  V(K)  that  contains  only  c-labels. 
By  Fact  1  we  know  that  V{K)  \—  0(c)  iff  VC(K)  \—  0(c).  Thus,  we  need  to  show  that  for 
all  K  >  1  and  for  all  c  £  [1  ..K] 

VA  \=  4>{x)  implies  VC{K)  (=  0(c). 

Now,  by  the  abstraction  theorem  modulo  renaming  (Fact  2),  it  suffices  to  show  that 
VC(K)  <c/x  VA  for  all  K  and  c  £{l..K] 

where  ^ c/x  denotes  simulation  modulo  renaming  as  defined  previously. 

We  will  now  prove  these  simulations. 

Step  2:  Proof  of  Simulation.  We  will  now  show  how  to  establish  the  simulation  relation 
VC{K)  -<c/x  VA  between  VC(K)  and  VA  for  all  K  >  1  and  c  £  [1..K],  To  this  end,  for 
each  K  and  c,  we  will  construct  an  intermediate  abstract  system  VAK  such  that 

70;  (70)  7c/;i;  'Pak  (Simulation  1) 

and 
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(Simulation  2) 


i  vA. 

The  required  simulation  then  follows  by  transitivity  of  simulation.  Intuitively,  the  inter¬ 
mediate  model  VAK  is  the  abstraction  of  the  K -process  non-parameterized  system  V(K) 
where  the  reference  process  c  is  fixed.  Thus,  VAK  is  obtained  from  PC(K )  by  “classi¬ 
cal”  predicate  abstraction.  Note  however  that  VAK  is  a  mathematical  construction  to  show 
soundness  of  the  abstract  model  VA.  In  the  implementation,  we  directly  construct  an 
approximation  of  VA. 

Construction  ofVAK.  The  abstract  model 

v$K  =  { d,iak,rak,la > 

is  defined  analogously  to  VA  for  the  special  case  where  K  and  c  are  fixed.  Thus,  VAK  is 
the  abstract  model  of  the  concrete  system  VC{K)  with  a  fixed  number  K  of  processes  and 
reference  process  c.  More  precisely,  VAK  is  defined  as  follows: 

(a)  The  state  space  D  is  the  same  as  in  VA. 

(b)  The  set  of  initial  states  IAK  is  the  subset  of  the  initial  states  1 4  of  VA  for  the  special 
case  of  K  and  c.  Thus,  IAK  is  given  by  those  abstract  states  A(x)  for  which  there 
exists  a  state  s  in  VC{K)  such  that  A(x)  G  ac(s). 

(c)  The  transition  relation  RAK  is  the  subset  of  the  transition  relation  /?  '  of  VA  for 
the  special  case  of  K  and  c.  Thus,  there  is  a  transition  from  A  |  (x)  to  A2(x)  in 
Rak  if  and  only  if  there  are  two  states  s i,  s2  in  VC(K)  such  that  A  |  (x)  e  ac(si), 
A2(x)  G  Oic(s2),  and  (si,  s2 )  G  R. 
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(d)  The  labeling  function  LA  is  the  same  as  in  VA. 


Proof  of  Simulation  1.  We  need  to  show  that  VC(K)  fc/x  VAK,  which  by  definition  of 
fc/x  is  equivalent  to 

Vc(K)[c/x]  i  VfK. 

Consider  the  structure  VC(K)  [c/x\.  This  is  just  the  A' -process  system  V(K)  restricted 
to  the  labels  for  process  c,  but  because  of  the  renaming  the  labels  have  the  form  l(x)  instead 
of  /(c).  Thus,  the  labels  of  VC{K)  [c/x]  are  taken  from  the  set  L.  Note  that  the  labels  of  the 
abstract  system  VA  are  also  taken  from  the  set  L.  The  proof  idea  below  is  similar  to  the 
construction  of  a  simulation  relation  for  existential  abstraction. 

Consider  the  relation 

1  =  {(s,  A(x))  :  s  [=  A(c),s  G  SKl  A(x)  G  D}. 

We  claim  that  X  is  a  simulation  relation  between  VC(K )  [c/x]  and  Vak: 

1.  Lemma  1  together  with  the  renaming  of  c  to  x  guarantees  that  for  every  tuple 
( s ,  A(x))  G  J,  the  states  s  and  A(x)  have  the  same  labels. 

2.  Consider  a  tuple  (s,  A(x))  G  I.  Assume  that  s  has  a  successor  state  s',  i.e.,  (s,  s')  G 
Rk-  We  need  to  show  that  there  exists  an  abstract  state  A'(x)  such  that 


(i)  (A(x),A'(x))  G  Rak,  and 

(ii)  (s',  A' (a;))  G  1. 
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To  find  such  a  A' (A),  consider  the  abstraction  ac(s')  of  s',  and  choose  some  descrip¬ 
tion  T(x)  G  ac(s').  By  the  coverage  condition,  ac(s’)  is  non-empty. 

We  will  show  by  contradiction  that  each  such  T  (x)  fulfills  the  properties  (i)  and  (ii) 
menitioned  above. 

Property  (i)  Assume  that  T(x)  does  not  fulfill  property  (i),  i.e.,  (A(A),T(A))  ^ 
RcK-  Then  for  all  states  si  and  s2  it  must  hold  that  whenever  A(A)  G  ac(si) 
and  T(A)  G  o;c(s2)  that  there  is  no  transition  between  si  and  s2.  On  the  other 
hand,  we  assumed  above  that  A(A)  G  ac(s),  T(x)  G  ac(V)  and  there  is  a 
transition  from  s  to  s'.  Hence  we  have  a  contradiction. 

Property  (ii)  Assume  now  that  r(rc)  does  not  fulfill  property  (ii),  i.e,  (s',  T(a;))  ^ 
X.  By  the  definition  of  X,  this  means  that  s'  T(c),  and  thus,  T(c)  ^  ac(s/). 
This  gives  us  the  required  contradiction. 

Thus,  A' (A)  can  be  chosen  from  among  the  descriptions  in  ac(s'). 

3.  Finally,  the  coverage  property  guarantees  that  for  every  initial  state  s  G  Ik  there 
exists  some  A(A)  G  I^K  s.t.  (s,  A(x ))  G  X. 

Proof  of  Simulation  2.  By  construction,  lfK  C  IA  and  RAK  C  /?'.  Therefore,  VA  is  an 
over- approximation  of  PAK,  and  the  simulation  follows.  □ 

Remark  5.  Note  that  the  coverage  and  congruence  requirements  for  D  and  L  are  used 
in  crucial  parts  of  Simulation  1  in  the  soundness  proof.  Congruence  is  used  in  the  proof 
of  Lemma  2.2.2  which  gives  us  property  1  of  Simulation  1.  Property  2  of  Simulation  1 
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requires  coverage  to  make  sure  that  ac(s')  is  non-empty.  Property  3  of  Simulation  1  also 
requires  coverage  to  ensure  the  existence  of  an  abstract  initial  state. 

Remark  6.  In  the  formulation  above,  we  have  not  assumed  that  processes  in  V(K)  execute 
synchronously  or  asynchronously.  That  is,  our  definitions  are  not  affected  by  how  the 
system  evolves.  We  only  assume  that  there  is  a  global  transition  relation  for  V(K).  Thus, 
results  described  above  hold  whether  the  processes  in  V(K)  execute  synchrounously  or 
asynchronously.  This  fact  will  allow  us  to  later  augment  V(K)  by  adding  synchronously 
executing  monitor  processes. 


2.4  Trade-Off  between  Expressive  Labels  and  Index  Vari¬ 
ables 


In  this  section  we  argue  why  a  well-chosen  set  of  labels  L  makes  it  often  possible  to 
use  a  single  index  variable.  The  Ptolemaic  system  view  explains  why  we  seldom  find  more 
than  two  indices  in  practical  specifications:  when  we  specify  a  system,  we  tend  to  track 
properties  the  reference  process  has  in  relation  to  other  processes  out  there,  one  at  a  time. 
Thus,  two-indexed  specifications  of  the  form 

Vz,  y-  x  ±  y  ->  <j>(x,y) 

often  suffice  to  express  the  specifications  of  interest.  Properties  involving  three  processes 
at  a  time  are  typically  complicated,  as  we  need  to  consider  a  triangle  of  processes  and  their 
relationships. 
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In  our  work  on  verifying  mutual  exclusion  and  cache  coherence  protocols,  we  used 
two  kinds  of  labels  (see  also  Example  2.2.1): 

•  pc[x]  =  L  and 

•  L  £  env(a;)  which  semantically  stands  for  3 y  x.p c[y\  =  L. 

Note  that  the  label  pc  [a;]  =  L  refers  only  to  process  x  whereas  L  £  env(x)  also  refers 
to  the  environment  of  x  using  a  hidden  quantification.  This  hidden  quantification  in  the 
environment  label  gives  surprising  power  to  single-indexed  specifications. 

To  see  this,  consider  the  standard  mutual  exclusion  property.  The  classical  way  to 
specify  mutual  exclusion  is  expressed  in  a  formula  such  as 

\/x,y.x  fiy  —>  AG  (pc  [a;]  =  5)  ->  (pc[y]  ^  5). 

It  is  easy  to  see  that  using  the  label  5  £  env(x),  we  can  express  this  specification  by  the 
logically  equivalent  single-indexed  formula 

Vx.AG  (pc[x]  =  5)  — >•  -i(3 y  x.p c[y\  =  5). 

which  is  in  turn  equivalent  to 

Vx.AG  (pc[x]  =  5)  — >  -i(5  £  env(x)) 

The  difference  between  the  three  formulas  is  that  in  the  first  specification  the  index 
quantifiers  are  in  prenex  form,  while  in  the  second  and  third  formula,  the  quantifier  for  y 
has  been  distributed  inside  the  formula,  and  is  hidden  in  the  label  5  £  env(x).  Again,  the 
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Ptolemaic  viewpoint  explains  why  such  situations  are  likely  to  happen:  in  many  specifi¬ 
cations,  we  consider  our  process  over  time  (i.e.,  using  a  temporal  logic  specification),  but 
only  at  the  individual  time  points  we  evaluate  its  relationship  to  other  processes.  Thus,  a 
time-local  quantification  suffices. 

The  interplay  between  labels  and  index  variables  gives  rise  to  interesting  logical  con¬ 
siderations  that  we  will  discuss  briefly  now. 

Distributive  Fragments  of  CTL  and  LTL.  It  is  natural  to  ask  when  a  double-indexed 
specification  can  be  translated  into  a  single-indexed  specification  as  in  the  example  above. 
Somewhat  surprisingly,  this  question  is  related  to  previous  work  on  temporal  logic  query 
languages  [73;  74;  75].  A  temporal  logic  query  is  a  formula  7  with  one  occurrence  of  a 
distinguished  atomic  subformula  “?”  (called  a  placeholder).  Given  7  and  a  formula  ip,  we 
write  7[,0]  to  denote  the  formula  obtained  by  replacing  ?  with  ip.  In  [73;  74;  75],  syntactic 
characterizations  for  CTL  and  LTL  queries  with  the  distributivity  property 

jbPi  A  ip2]  <-*•  q#i]  A  7(^2]- 

are  described.  A  template  grammar  for  the  distributive  fragment  of  LTL  is  given  in  the 
appendix  of  [74]. 

The  prototypical  example  of  a  distributive  query  is  AG?,  and  we  have  seen  above 
that  for  AG  properties,  we  can  translate  double  indexed  properties  into  single-indexed 
properties.  As  argued  above,  this  translation  actually  amounts  to  distributing  one  universal 
quantifier  inside  the  temporal  formula. 

Such  a  translation  is  possible  for  all  specifications  which  are  distributive  with  respect 
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to  one  index  variable:  consider  a  double-indexed  specification  Mx,  y.  x  0  y  — >  Mx,  y ) 
where  all  occurrences  of  y  in  0  are  located  in  a  subformula  0(x.  y)  of  0.  Then  we  can 
write  0  as  a  query  y[6\.  Now  suppose  that  7  is  distributive.  On  each  finite  V(K),  the 
universal  quantification  reduces  to  a  conjunction,  i.e., 

V{K)  |=  Mx,  y.  x  i-  y  -*•  j[6(x,  y)}  iff  V{K)  |=  Mx.  f\  7 [6(x,  c)] 

l<c<K  ,c^x 

which  by  distributivity  of  7  is  equivalent  to 

V{K)  h  Mx.  7  A 

_l<c<K,i^x 

and  thus  to 

V(K)  |=  Mx.  7  [  My.x  ^  y  — > ►  0(x,  c)  ] . 

For  a  suitable  label  Z(x)  :=  My.  x  ^  y  — >  0(x,  y)  this  can  be  written  as 

P(iT)  h  Vx.  7[/(x)]. 

For  the  important  special  case  where  9(x,  y)  has  the  form  pc[y]  =  L,  this  is  equivalent  to 

V(K)  [=  Mx.  7 [L  env(x)]. 

While  the  characterization  of  distributive  queries  gives  us  a  good  understanding  about 
the  scope  of  single-indexed  specifications,  it  is  clear  that  not  all  two-indexed  specifications 
can  be  rewritten  with  a  single  index.  Consider,  for  example,  the  formula 

Mx,y.x  7^  y  — ^  AF(pc  M  =  5  A  pc[y]  =  5). 

Here  it  is  evidently  not  possible  to  move  the  quantifier  inside.  This  can  also  be  derived 
from  the  characterization  in  [74].  Consequently,  this  specification  cannot  be  expressed 
with  a  single  index. 
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In  Section  2.5.1  we  will  show  how  to  extend  environment  abstraction  to  multiple  ref¬ 
erence  processes.  Of  course,  having  more  reference  processes  will,  in  general,  make  the 
abstract  model  larger,  and,  thus,  harder  to  analyze.  This  motivates  the  following  approach 
to  deal  with  two-indexed  specifications  a: 

1.  Using  the  grammar  characterizations  of  distributive  queries,  determine  whether  a 
can  be  written  with  a  single  index. 

2.  Otherwise,  use  an  abstraction  with  two  reference  processes,  as  described  in  Sec¬ 
tion  2.5.1. 

2.5  Extending  Environment  Abstraction 

In  this  section,  we  will  describe  a  few  easy  extensions  to  environment  abstraction. 

2.5.1  Multiple  Reference  Processes 


In  the  preceding  sections,  we  focused  on  a  framework  for  single-indexed  specifications 
of  the  form  Vx.(f)(x).  Extending  this  framework  to  two  reference  processes  is  simple  - 
essentially,  we  need  to  replace  the  free  variable  x  in  the  process  properties  by  a  pair  x,  y, 
and  carry  this  modification  through  all  definitions  and  proofs.  The  generalization  to  more 
indices  is  straightforward,  and  left  to  the  reader. 
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For  the  set  D  of  descriptions,  we  will  now  use  descriptions  of  the  form  A(x,  y )  which 
capture  the  state  of  two  reference  processes  x,  y  and  the  environment  around  them.  Thus, 
we  can  track  the  mutual  relationship  of  two  processes  in  greater  detail.  Similarly,  we  can 
extend  the  set  of  labels.  The  set  L  of  labels  is  partitioned  into  unary  labels  L1  of  the  form 
l(x)  and  binary  labels  L2  of  the  form  l(x,y).  Note  that,  in  practice,  the  single-indexed 
labels  will  usually  suffice.  A  state  s  of  system  V(K)  is  labeled  with  /(c)  if  and  only  if 
s  (=  1(c).  State  s  is  labeled  with  l(c,  d)  if  and  only  if  s  \—  l(c,  d). 

The  coverage  and  congruence  requirements  are  generalized  analogously: 

1.  Coverage.  For  each  system  V(K),  each  state  s  in  V(K)  and  any  two  processes  c,  d 
there  is  some  description  A(x,  y)  G  D  which  describes  the  properties  of  c,  d,  i.e., 

s  f=  A(c,  d). 

2.  Congruence.  For  each  description  A  (a;,  y)  G  D  and  each  label  l{x,  y)  G  L 2  it  holds 
that  either  A(x,  y)  —>  l(x ,  y)  or  A  (a;,  y)  — >  ->l(  x,  y).  An  analogous  condition  holds 
for  labels  in  L1. 

Thus,  we  obtain  a  natural  definition  of  the  abstraction  mapping: 

Definition  2.5.1.  Given  a  concrete  state  s  and  two  processes  c  and  d,  the  abstraction  of  s 
with  reference  processes  c  and  d  is  given  by  the  set 

ac,d(s)  =  {^(x,y)  e  D  :  s\=  A  (c,d)}. 

The  construction  of  the  abstract  model  is  analogous  to  the  single  index  case.  To  in¬ 
dicate  the  number  of  reference  processes  in  the  abstract  model,  we  write  P.f  for  the  ab- 
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stract  model  with  two  reference  processes.  Analogously  to  the  single-index  case,  we  at¬ 
tach  labels  to  each  state  of  V £  such  that  the  abstract  state  A (x,y)  has  label  l(x,y)  iff 
A(x,y)  -*•  l(x,y). 

Theorem  2.5.2  (Soundness  of  Double-Index  Environment  Abstraction).  Let  V(K)  be 
a  parameterized  system  and  Pf  be  its  abstraction  with  two  reference  processes.  Then  for 
double  indexed  ACTL*  specifications  \/x  f  y.oix.  y)  the  following  holds: 

P2a  |=  f(x,y)  implies  VK.V(K)  |=  \/x  y.<fr(x,y). 

The  environment  abstraction  principle  can  be  easily  extended  to  incorporate  more  than 
two  reference  processes.  As  argued  above,  it  is  quite  unlikely  that  a  practical  verification 
problem  will  require  the  use  of  three  reference  processes. 

2.5.2  Adding  Monitor  Processes 


Often  times  it  is  necessary  to  augment  a  given  parameterized  system  V(K)  by  adding 
non-interfering  monitor  processes.  Monitors  are  essentially  synchronous  processes  (i.e., 
they  execute  at  every  step  of  V{K))  that  maintain  history  information  regarding  the  pro¬ 
cesses  in  V{K).  Addition  of  monitors  gives  more  information  about  the  evolution  of  the 
system.  Thus,  taking  monitors  into  account  during  abstraction  can  give  us  better  abstract 
models.  A  typical  case  where  monitors  are  needed  is  for  handling  liveness  properties. 
As  we  will  see  later  in  Section  4.4,  environment  abstraction,  as  described  in  the  earlier 
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sections,  is  too  coarse  to  handle  liveness  properties.  This  is  because  the  abstraction  can 
introduce  spurious  loops,  which  can  lead  to  false  negatives.  These  spurious  abstract  be¬ 
haviors  can  be  eliminated  by  augmenting  the  system  V(K)  with  monitors  and  abstracting 
the  augmented  system.  While  the  precise  details  of  monitor  processes  are  considered  later 
in  Chapter  4,  we  will  consider  here  the  theoretical  basis  for  adding  monitors. 

Consider  a  parameterized  system  V(K)  and  assume  that  we  augment  it  by  adding 
a  collection  of  identical  monitor  processes  M(  1), . . . ,  M(K).  Each  M(i )  is  exactly  the 
same  as  the  other  monitor  processes  except  for  its  id.  Denote  the  augmented  param¬ 
eterized  system  by  VM(K).  The  states  of  VM(K )  are  given  by  tuples  of  the  form 
sm  =  (Ci, . . . ,  CkiM.1i  ■  ■  ■  i  Mk)  where  C%  is  denotes  local  state  of  process  P(i)  and 
Mi  denotes  the  local  state  of  the  monitor  process  M(i). 

The  results  presented  in  Section  2.2  assume  there  is  only  one  collection  of  replicated 
process.  To  make  the  results  of  Section  2.2  applicable,  we  can  compose  each  M{i) 
with  the  corresponding  P(i)  to  create  a  hybrid  process  PM{i).  The  augmented  system 
VM(K)  =  (Sm,  hi,  Rm,  Cm )  is  a  parameterized  system  with  PM(i)’ s  as  the  constitut¬ 
ing  processes.  The  set  of  labels  LM  is  usually  the  same  as  the  set  of  labels  L  of  V(K).  To 
apply  environment  abstraction  to  VM(K)  we  just  have  to  pick  the  appropriate  set  of  ab¬ 
stract  descriptions  satisfying  the  congruence  and  coverage  properties  together  with  labels 
in  L.  Let  Dm  be  a  collection  of  abstract  descriptions  A m(x)  and  a m  be  the  abstraction 
mapping  from  Sm  to  DM  such  that  DM  satisfies  the  coverage  and  congruence  conditions 
with  respect  to  the  set  of  labels  L. 

Define  the  augmented  abstract  model  Vfr  in  the  usual  fashion. 
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Definition  2.5.3  (Augmented  Abstract  Model).  The  abstract  model  of  a  parameter¬ 
ized  system  VM(K)  is  defined  as  the  Kripke  structure  ( DM ,  ify,  Rfr,  Lfr)  where 

•  Dm  is  the  set  of  all  augmented  abstract  descriptions 

•  I^r.  the  set  of  initial  abstract  states,  is  the  set  of  augmented  abstract  states  §m  such 
that  there  exists  a  concrete  initial  state  sm  of  a  concrete  system  VM(K),  K  >  1, 
and  a  process  p  G  [1. .K],  such  that  q;mp(sm)  =  %• 

•  R^j  is  defined  as  follows:  There  is  a  transition  from  abstract  state  %i  to  abstract 
state  §m2  if  there  exist 

(i)  a  concrete  system  VM(K),  K  >  1  with  a  process  p 

(ii)  a  concrete  transition  from  concrete  state  sMl  to  s M2 
in  VM(K) 

such  thataMp(si)  =  sMl  and  aMp(s2)  =  sM2- 

•  Am(x)  is  labeled  with  l{x)  G  L  if  and  only  if  AM(x)  =>  l(x). 

Corollary  1.  Let  TM.(K)  be  the  augmented  parameterized  system  corresponding  to  the 
parameterized  system  V(K).  Let  Vfr  be  the  augmented  abstract  model  as  described  above. 
Then,  for  any  single  indexed  ACTL*  specification  \/x.(f)(x),  where  (p(x)  is  a  formula  over 
labels  L,  we  have 

h  Hx)  =>  VA'  >  l.VM(K)  |=  \/x.(f)(x) 

Proof.  This  follows  simply  from  Theorem  2.2.4.  Note  that  we  are  using  the  fact  that 
Theorem  2.2.4  holds  whether  the  parameterized  system  V(K)  executes  asynchronously  or 
not.  □ 
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Since  we  have  assumed  that  the  monitors  are  non-interfering,  VAi(K)  |=  'ix.o(x) 
implies  V(K)  |=  \/x.(j)(x).  Thus 

V&  |=  <f>(x)  =>  V/i  >  l.VM(K)  |=  Vx.<f>{x)  =>>  V/i  >  1  .V(K)  \=  Vx.<f>{x) 

Remark  7.  Note  that  the  number  of  monitor  processes  is  exactly  the  same  as  the  number 
of  processes.  This  does  not  reduce  the  generality  of  the  results  above  for  the  following 
reasons:  if  the  number  of  monitor  processes  is  constant  (i.e.,  independent  of  K)  then  they 
can  be  treated  as  one  single  non-replicated  process.  On  the  other  hand  if  the  number 
of  monitors  was  a  function  of  K  then  we  can  compose  a  set  of  monitors  and  processes 
(instead  of  one  monitor  and  one  process)  to  create  composite  processes.  For  example, 
suppose  we  had  only  K/2  monitors  in  the  system  V(K)  with  K  processes.  Then  we 
can  compose  two  processes  and  one  monitor  to  create  a  larger  composite  process 
and  the  augmented  parameterized  system  is  composed  of  K/2  such  composite  processes. 
Thus,  our  results  will  still  be  applicable. 


2.6  Example  of  Environment  Abstraction 

We  have  thus  far  described  environment  abstraction  in  its  most  general  terms.  We  have 
not  indicated  what  descriptions  to  choose  or  what  labels  to  use  beyond  specifying  their 
general  forms.  In  the  following,  we  discuss,  using  an  example,  some  of  these  issues  which 
let  us  apply  this  abstraction  method  to  practical  systems. 
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2.6.1  Abstract  Descriptions 


Consider  abstract  descriptions  of  the  form  A(x)  consisting  of  a  single  reference  process.  A 
description  A(x)  can  provide  very  detailed  information  on  process  x  and  its  environment. 
In  our  work  on  verifying  mutual  exclusion  protocols  (see  Chapter  4),  we  found  it  useful 
to  have  descriptions  A  (a;)  of  the  following  form: 

A(x)  =  pc  [a;]  =  L  A  By  ^  x.Ei(x,  y)  A  . . .  3y  ^  x.ET(x,  y),T  >  1 

Informally,  the  condition  pc  [a;]  =  L  describes  the  control  location  of  the  reference  process 
x.  Each  of  the  conditions  3 y  ^  x.E,  (x.  y )  tells  that  there  exists  a  process  y  in  the  environ¬ 
ment  of  x  satisfying  a  certain  predicate  Ei(x,  y)  over  the  state  variables  of  processes  x,  y. 
Each  Ei(x,  y)  itself  is  of  the  form 

Ei(x,y)  =  ±R1(x,y)  A  ...  A  ±RM(x,y)  A  pc [y]  =  L,  M  >  1 

where  each  Ri(x,  y)  is  an  atomic  predicate  relating  the  data  variables  of  two  processes  x.  y. 
The  condition  p c[y\  =  L  says  that  process  y  is  in  control  state  L.  That  is,  we  take  every 
possible  cube  over  the  atomic  predicates  R\(x,  y), . . . ,  Rm(x,  y)  (that  is, every  expression 
of  the  form  ±R1  (x,y)  A ...  A  ±Rm  (x-  y)  and  conjoin  them  with  every  possible  predicate  of 
the  form  pc [y]  =  L  to  obtain  the  full  set  of  E,(x.  y)  predicates.  It  is  easy  to  see  that  every 
process  y  in  the  environment  of  a  process  x  will  satisfy  one  of  the  Er{x,  y)  predicates.  It 
is  also  easy  to  see  the  set  of  descriptions  as  constructed  above  has  the  required  coverage 
property:  for  all  concrete  systems  V{K),  each  concrete  s  of  ViK)  and  process  c  G  [1. .K], 
s  |=  A(c)  for  some  description  A  (a;). 

The  choice  of  the  set  of  descriptions  was  dictated  by  the  properties  that  we  were  inter- 
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ested  in  verifying,  namely,  two  index  safety  properties  of  the  form 


Vx,y.x  /  j/A  (pc[x]  =  crit  =>■  -i(pc[t/]  =  crit) 

As  discussed  earlier,  this  property  can  be  equivalently  written  as 

Vx.(pc[x]  =  crit  -i(3 y  x.p c[y\  =  crit)) 

Thus,  the  two  indexed  property  is  essentially  composed  of  two  kinds  of  labels 
•  pc[x]  =  L,  and 
•3 y  f  x.pc [y]  =  L. 

Observe  first  that  only  x  occurs  free  in  both  types  of  labels.  Further,  each  description 
A(x)  either  implies  pc[x]  =  L  or  its  negation.  Similarly,  each  A(x)  either  implies  3 y  f 
x.p c[y\  =  L  or  its  negation.  Thus,  we  also  have  the  required  congruence  property.  Thus, 
the  set  of  descriptions  we  chose  have  both  congruence  and  coverage  properties  required 
by  our  abstraction  framework. 

As  an  aside,  if  we  let  3fc  stand  for  the  generalization  of  the  usual  existential  quantifier 
3  meaning  there  exist  at  least  k  different  elements,  then  our  descriptions  can  be  made  even 
stronger.  Instead  of  the  descriptions  above  we  can  use 

A(x)  =  pcfrc]  —  L  A  3 ky  x.Ei(x,  y)  A  . . .  3 ky  x.ET(x,  y). 

Instead  of  just  telling  us  whether  there  is  a  process  satisfying  Efx,  y)  these  descriptions 
also  tell  us  whether  there  are  atleast  k  such  processes  or  not.  Note  that  this  is  quite  close 
in  spirit  to  counting  abstraction  which  also  counts  processes  satisfying  certain  conditions 
(though  there  is  no  notion  of  a  reference  process  in  counting  abstraction). 
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2.7  Related  Work 


Verification  of  parameterized  systems  is  well  known  to  be  undecidable,  see  [2;  76]. 
Nonetheless,  many  interesting  approaches  to  this  problem  have  been  developed  over  the 
years,  including  the  use  of  symbolic  automata-based  techniques  [1;  10;  12;  51],  invari¬ 
ant  based  techniques  [3;  64],  predicate  abstraction  [52],  and  symmetry  [24;  31;  38;  39; 
40].  Some  of  the  earliest  work  on  verifying  parameterized  systems  includes  the  works 
by  Browne  et  al  [14;  15],  German  and  Sistla  [43],  and  Emerson  and  Sistla  [38].  Pa¬ 
pers  that  handle  systems  similar  to  the  parameterized  systems  considered  in  this  thesis 
are  [3;  6;  7;  41;  42;  52;  53;  64;  66].  The  paper  [66]  by  Pnueli  et  al.,  which  introduces  the 
term  counter  abstraction ,  inspired  our  work. 

Environment  abstraction  fits  the  Abstract  Interpretation  framework  of  Cousot  and 
Cousot  [26].  In  the  Abstract  Interpretation  framework  one  studies  the  effect  of  a  program 
in  an  abstract  domain  instead  of  the  concrete  domain  that  the  program  is  supposed  to 
handle.  The  abstract  domain  is  designed  to  be  sound  so  that  a  property  that  holds  in  the 
abstract  domain  will  also  hold  in  the  concrete  domain.  While  this  provides  a  general 
methodology,  it  provides  no  guidance  on  what  abstract  domain  to  choose.  The  choice 
of  the  abstract  domain  to  consider  is  in  fact  the  toughest  question  facing  any  Abstract 
Interpretation  based  method. 

In  the  context  of  verifying  software  and  hardware  systems,  several  different  alternatives 
have  been  proposed  to  construct  abstract  domains.  Any  such  method  must  address  two 
conflicting  issues: 
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Generality:  The  abstract  domains  must  be  as  widely  applicable  as  possible.  It  de¬ 
feats  the  propose  of  automated  and  efficient  program  analysis  if  the  user  has  to  figure 
out  the  abstract  domain  for  each  and  every  program  separately.  Thus,  it  is  required 
that  methods  for  constructing  the  abstract  domains  should  not  be  too  specific. 

Usability:  On  the  other  hand,  widely  applicable  but  trivial  abstract  domains  can  be 
constructed  quite  easily.  Such  abstract  domains  are  useless  in  proving  interesting 
properties  of  a  program  under  consideration.  It  is  typically  the  case  that  the  more 
widely  a  method  (for  constructing  abstract  domains)  is  applicable,  the  less  powerful 
it  is. 


In  this  thesis,  we  are  essentially  proposing  a  new  approach  for  constructing  abstract 
domains.  This  approach  is  applicable  to  any  system  that  has  replicated  components.  For 
such  systems,  the  abstract  domain  we  consider  has  detailed  information  on  one  reference 
component  and  the  rest  of  the  components  are  considered  in  less  detail  and  in  relation 
to  the  reference  component.  It  is  our  claim  that  this  is  the  way  a  human  designer  thinks 
(when  designing  systems  with  replicated  components),  and,  hence  the  abstract  domains 
constructed  according  to  this  pattern  will  be  powerful.  It  is  to  be  noted  that  we  have  not 
specified  all  the  details  of  the  abstract  domain  as  they  necessarily  depends  on  the  specific 
class  of  programs  under  consideration.  But  following  this  general  structure,  we  hope  that 
filling  in  the  details  will  be  easy. 

In  the  following  sections  we  discuss  some  of  the  well  known  abstraction  methods  and 
how  they  relate  to  our  work. 
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2.7.1  Predicate  abstraction 


This  method,  proposed  by  Graf  and  Saidi  [70;  72]  has,  over  the  years,  become  one  of  the 
most  widely  used  abstraction  mechanisms  for  handling  systems  with  large  or  unbounded 
state  spaces.  The  basic  idea  of  this  approach  is  to  consider  the  effect  of  the  program  on  a  set 
of  (carefully  chosen)  predicates.  The  abstract  domain  consists  of  a  set  of  predicates  over 
the  program  variables.  Assume  that  the  set  of  predicates  is  V  =  (Pi, . . . ,  Pn}.  The  ab¬ 
stract  domain  consists  of  all  possible  valuations  (bi, . . . ,  bn)  of  the  predicates  Pi, ... ,  Pn. 
Denote  the  set  of  concrete  states  by  S  and  the  set  of  abstract  states  by  S.  We  can  then 
define  the  standard  abstraction  mapping  a  from  S  to  abstract  states  S  as  follows.  For  any 
concrete  state  s  G  S  and  (&i, _ rbn)  G  S 

a(s)  =  bn)  such  that  each  bt  =  1  iff  s  |=  Pj. 

The  corresponding  concretization  mapping  7  from  S'  to  2 5  is  then  defined  as 

7((&i, .  .  . ,  bn))  =  (s|q;(s)  =  bn)} 

Once  the  abstraction  mapping  is  defined,  the  abstract  model  is  described  using  the  well- 
known  existential  definition:  given  two  abstract  states  si,  s 2  there  is  an  abstract  transition 
from  si  to  .s- 2  if  there  exist  two  concrete  states  si,  s2  such  that 


•  a(si)  =  si, 

•  Q;(s2)  =  s2,  and 

•  there  is  a  concrete  transition  from  ,s  1  to  .s'2. 
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It  can  be  shown  that  the  abstract  model  so  defined  is  a  conservative  abstraction  of  the 


concrete  system  [70]. 

Predicate  abstraction  is  a  very  general  method.  The  main  problem  in  applying  pred¬ 
icate  abstraction  is  in  deciding  what  set  of  predicates  to  use.  This  is  an  active  area  of 
research  and  several  heuristics  are  used  to  discover  relevant  predicates  to  use  (for  example 
the  CEGAR  loop  [22]).  In  contrast,  our  method  does  provide  a  framework  for  constructing 
predicates. 

There  are  some  crucial  differences  between  standard  predicate  abstraction  and  our 
method.  Given  a  fixed  set  of  predicates,  each  concrete  state  can  map  only  to  one  ab¬ 
stract  state  in  usual  predicate  abstraction.  On  the  other  hand,  in  our  abstraction  method,  a 
concrete  state  can  map  to  multiple  abstract  states  depending  on  which  process  is  chosen  as 
the  reference  process. 

Further,  in  standard  predicate  abstraction,  the  predicates  typically  involve  the  variables 
of  the  same  process/program.  In  our  approach,  the  predicates  span  multiple  processes  and 
relate  the  states  of  different  components  in  the  system.  TVLA  [71;  80]  was  the  first  work 
to  identify  the  importance  of  such  predicates  and  it  has  been  successfully  used  to  verify 
various  multi-threaded  systems  and  heap  properties.  We  believe  the  use  of  predicates  re¬ 
lating  different  processes/components  within  a  system  is  a  natural  and  powerful  extension 
of  standard  predicate  abstraction.  Such  predicates  are  required  if  one  wants  to  verify  multi 
process  systems  or  reason  about  heap  properties. 
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2.7.2  Indexed  Predicates 


The  Indexed  Predicates  approach  was  proposed  by  Lahiri  and  Bryant  [52;  53]  to  handle 
unbounded  systems  such  as  those  with  replicated  processes  or  unbounded  data  structures. 
The  invariants  of  such  systems  are  usually  quantified  over  the  parameters  and  the  indices 
of  the  various  components  of  the  system.  Typically,  the  scope  of  the  quantifiers  contains 
complex  formulas  (which  are  themselves  composed  of  smaller  predicates  containing  free 
index  variables).  If  one  were  to  use  standard  predicate  abstraction,  discovering  such  invari¬ 
ants  would  involve  predicates  which  are  almost  as  complex  as  the  invariants  themselves. 
To  get  around  this  problem,  the  Indexed  Predicates  approach  uses  simple  predicates  which 
can  contain  free-index  variables  and  tries  to  build  complex  quantified  invariants  from  these 
indexed  predicates.  The  invariants  discovered  using  this  method  contain  only  universal 
quantifiers. 

The  Indexed  Predicates  starts  with  a  set  of  predicates  V  =  (Pi, . . . ,  Pn }  which  can 
contain  free  index  variables  from  a  set  X .  As  with  standard  predicate  abstraction,  the 
abstract  state  space  S  is  just  the  set  of  all  possible  valuations  (b\, ... ,  bn)  of  the  atomic 
predicates  in  V.  The  abstraction  mapping  function  though  is  quite  different.  A  concrete 
state  s  maps  to  an  abstract  state  s  =  (bi, ...  ,bn)  if  for  some  valuation  of  the  index  variables 
in  X  the  value  of  each  predicate  P*  in  V  matches  the  corresponding  bi  in  s.  More  formally, 
let  v(X)  denote  some  valuation  of  the  index  variables  in  X .  Then 

a(s)  =  {s6  Sj3v(A’).(s  \=v(x)  Pi  O  bi)} 

where  s  \=v(x)  Pi  means  state  s  satisfies  predicate  P,  with  all  the  free  index  variables 
occuring  in  Pi  fixed  according  to  the  valuation  v(X). 
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Since  there  are  multiple  possible  valuations  for  variables  in  X,  a  single  concrete  state 
can  map  to  several  different  abstract  states.  Note  that,  in  our  method  a  single  concrete  state 
can  also  map  to  several  different  abstract  states  depending  on  which  process  is  chosen  as 
the  reference  process  (the  reference  process  in  our  method  can  be  modeled  as  a  free  index 
variable).  Thus,  the  abstraction  mapping  used  in  our  method  and  in  Indexed  Predicates 
are  essentially  the  same.  But  unlike  our  method,  Indexed  Predicates  method  defines  a 
concretization  function  for  a  set  of  abstract  states,  not  for  a  single  abstract  state.  The 
concretization  of  a  set  of  abstract  states  C  is  the  set  C  of  concrete  states  such  that,  for  all 
valuation  of  the  free  index  variables,  every  state  s  G  S  maps  to  some  state  s  <G  S.  More 
formally,  for  a  set  C  of  abstract  states 


7 ((7)  =  {C  C  S' | Vs  e  C.a(s)  C  6} 

The  abstract  reachability  is  carried  out  by  defining  a  reachability  function  that  operates 
on  sets  of  abstract  states  instead  of  single  abstract  states.  Denote  the  concrete  transition 
relation  by  p.  Then  the  abstract  reachability  function  p  is  defined  as: 

P(S)  =  a(p(  l(S))- 


Let  R,  R  be  the  set  of  concrete  and  abstract  reachable  states.  Then  it  can  be  shown 


that  [53] 


a(R)  C  R. 


Thus,  an  over-approximation  of  the  concrete  reachable  states  can  be  found  by  doing  a 
reachability  analysis  on  the  abstract  model. 
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A  crucial  difference  between  our  method  and  Indexed  Predicates  method  is  that  we  can 


define  a  concretization  function  that  operates  on  individual  abstract  states  instead  of  sets 
of  abstract  states.  In  our  framework,  the  concretization  function  7  is  defined  as  follows. 
For  an  abstract  state  s 

7 (s)  =  (s  G  Sj3c.ac(s)  =  s} 
where  c  is  the  reference  process. 

Because  we  can  talk  of  concrete  states  corresponding  to  each  abstract  state,  we  can  also 
define  an  abstract  transition  relation,  not  just  an  abstract  reachability  function  operating  on 
sets  of  states  (as  in  Indexed  Predicates.  2)  As  a  consequence,  Indexed  predicates  method  is 
not  suited  for  handling  liveness  properties,  which  requires  an  abstract  transition  relation. 
Indexed  Predicates  method  can  verify  only  safety  properties.  In  contrast,  our  approach  can 
handle  both  safety  and  liveness  properties. 

In  Indexed  Predicates,  the  computation  of  the  abstract  reachable  states  is  done  symbol¬ 
ically  by  reducing  each  step  of  the  reachability  analysis  to  finding  solutions  of  a  quantified 
CLU  formula  (CLU  logic  is  a  subset  of  first  order  logic  with  uninterpreted  functions  [18]). 
Quantified  CLU  formulas  are  then  solved  by  posing  them  as  Boolean  SAT  problems  [17]. 
Observe  that  this  method  of  abstract  reachability  does  not  really  exploit  our  knowledge  of 
the  concrete  transition  statements.  On  the  flip  side,  the  systems  that  Indexed  Predicates  can 
handle  is  limited  in  theory  only  by  the  availability  of  solvers  for  first  order  logic  formulas. 

In  contrast,  in  our  approach,  we  consider  each  statement  of  the  protocol  and  compute 
an  over- approximation  of  all  the  abstract  transitions  this  can  lead  to.  In  doing  this,  we 
2As  an  aside,  we  believe  the  Indexed  Predicates  method  can  also  be  generalized  to  have  an  abstract 
transition  relation. 
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are  able  to  exploit  our  knowledge  of  the  transition  statements  whereas  Indexed  Predicates 
cannot.  This  means  that,  for  each  type  of  transition  statement,  we  have  to  write  by  hand 
an  over-approximation  for  it.  We  believe  this  is  a  novel  feature  of  our  approach:  the  user 
has  to  provide  an  over- approximation  for  each  type  of  transition  statement  in  the  system. 
Since  there  are  limited  number  of  different  types  of  transition  statements  (in  our  work  on 
protocol  verification  we  had  around  6  types),  this  is  a  fairly  easy  task. 

Another  difference  between  the  two  approaches  is  that  Indexed  Predicates  is  a  general 
framework  much  in  the  spirit  of  standard  predicate  abstraction  and  TVLA.  It  provides  no 
guidance  on  what  predicates  to  use.  This  problem  is  compounded  by  the  fact  that,  unlike 
predicate  abstraction,  there  is  no  possibility  of  applying  the  Counterexample  Guided  Ab¬ 
straction  loop  to  extract  useful  predicates.  This  is  because  there  is  no  abstract  transition 
relation  in  Indexed  Predicates  and  consequently,  no  notion  of  an  abstract  trace.  Our  ap¬ 
proach,  in  contrast,  does  provide  a  guideline  for  what  predicates  to  use.  Moreover,  as  we 
have  an  abstract  transition  relation,  automatic  predicate  discovery  guided  by  counterexam¬ 
ple  traces  is  also  possible. 


2.7.3  Three  Valued  Logical  Analysis  (TVLA) 

The  TVLA  method  proposed  by  Reps  et  al.  [71;  80]  is  an  abstract  interpretation  based 
approach  for  verifying  safety  properties  of  multi-threaded  systems,  and  for  doing  shape 
analysis.  This  is  a  widely  applicable  method  that  uses  the  universe  of  first  order  logical 
structures  as  the  abstract  domain.  To  make  verification  of  unbounded  systems  possible, 
they  use  the  notion  of  summarization,  which  is  similar  to  the  idea  of  counting  abstraction. 
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The  essential  idea  is  to  represent  the  state  of  a  system  as  a  first  order  structure  (called 
a  configuration)  consisting  of  objects  and  predicates  over  these  objects.  The  objects  in 
the  first  order  structure  can  be  used  to  represent  threads  and  heap  allocated  data  structures. 
The  predicates  can  be  used  to  represent  relationships  between  the  objects.  For  example,  the 
fact  that  a  pointer  p  points  to  thread  t  can  be  represented  by  using  a  predicate  pointsTo(p,t). 
Papers  on  TVLA  were  the  first  to  observe  that  predicates  spanning  or  relating  multiple 
components  of  a  system  are  essential  if  we  want  to  reason  about  multi-threaded  systems 
and  heap  properties. 

Once  a  set  of  relevant  predicates  have  been  picked,  the  mapping  from  concrete  states 
to  abstract  states  is  straight-forward.  There  is  a  one  to  one  mapping  from  the  threads  and 
other  components  of  the  concrete  system  to  the  objects  in  the  abstract  domain.  Further,  the 
valuations  of  the  different  predicates  are  known  from  the  concrete  state  being  considered. 
If  the  number  of  threads  and  other  components  in  the  concrete  system  are  bounded  then 
the  number  of  objects  necessary  in  the  abstract  domain  is  also  finite. 

To  handle  the  case  where  the  concrete  system  can  have  an  unbounded  number  of 
threads  and  other  components,  TVLA  uses  the  notion  of  summarization  which  is  essen¬ 
tially  a  form  of  counting  abstraction.  Suppose  components  ci, ...  ,cn  all  satisfy  the  same 
set  of  unary  predicates  3.  Then  instead  of  mapping  them  to  different  objects  ou ... .  on  in 
the  abstract  domain,  they  are  mapped  to  one  abstract  object  o.  Thus,  an  unbounded  num¬ 
ber  of  concrete  components  can  be  summarized  using  a  single  abstract  object  o.  Observe 
that  summarization  of  0\, . . . ,  on  into  one  abstract  object  b  introduces  uncertainty  in  the 

3TVLA  uses  binary  predicates  to  specify  relationship  between  different  components  and  unary  predicates 
to  specify  properties  of  a  particular  component. 
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properties  satisfied  by  d.  For  instance,  suppose  object  oi  satisfies  a  certain  binary  predi¬ 
cate  Bin(oi,t)  for  some  fixed  arguement  t,  but  the  rest  of  the  objects  do  not.  It  is  not  clear 
in  this  case  whether  6  should  satisfy  Bin(d ,  t )  or  not.  To  deal  with  situations  like  these, 
TVLA  uses  three-valued  logic  (hence  the  name)  instead  of  the  standard  two-valued  logic. 
Thus,  a  predicate  P  can  take  three  values  0, 1/2,  and  1,  where  0, 1  have  the  usual  meaning 
and  1/2  denotes  that  P  can  have  either  value. 

While  summarization  of  similar  objects  is  a  powerful  feature  that  lets  TVLA  deal  with 
unbounded  systems,  it  is  sometimes  necessary  to  track  one  object, say  o\,  separately  from 
other  objects  o2, . . . ,  on  even  though  they  may  have  the  same  properties.  For  this  sake, 
special  unary  predicates  can  be  used  to  select  some  particular  object  as  a  special  object 
and  thus  track  its  execution  in  detail.  Such  unary  predicates  used  to  distinguish  individual 
objects  are  called  instrumentation  predicates. 

It  might  seem  that  instrumentation  predicates  can  be  used  to  simulate  our  notion  of  a 
reference  process,  but  that  is  not  the  case.  The  only  thing  that  distinguishes  a  reference 
process  from  other  processes  in  the  system  is  its  id.  Thus,  if  we  use  instrumentation 
predicates  to  simulate  the  notion  of  a  reference  process,  the  predicates  will  have  to  refer 
to  the  process  ids.  This  means  that  once  a  reference  process  is  chosen  by  instrumentation 
predicates  it  cannot  change.  But,  in  our  abstraction,  the  identity  of  the  process  that  serves 
as  the  reference  process  may  change  from  transition  to  transition.  Thus,  the  notion  of  a 
reference  process  cannot  be  simulated  using  instrumentation  predicates. 

To  explore  the  state  space  of  a  given  system,  TVLA  starts  with  the  initial  set  of  ab¬ 
stract  configurations  each  of  which  corresponds  to  some  concrete  initial  state.  The  actions 
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of  the  concrete  system  rewrite  the  abstract  configurations  into  new  configurations.  TVLA’s 
model  checker  performs  on-the-fly  model  checking  by  exploring  new  configurations  until 
all  the  configurations  are  covered.  Because  of  summarization,  the  set  of  abstract  configura¬ 
tions  is  bounded,  and  the  explicit  exploration  of  the  abstract  domain  will  terminate.  Thus, 
no  abstract  model  is  built  up  front  on  which  model  checking  is  performed.  In  contrast,  in 
our  method  we  build  an  abstract  model  up  front. 

The  framework  proposed  by  TVLA  is  extremely  general;  essentially  any  real  world 
system  can  be  handled  by  this  framework.  Consequently,  no  method  for  choosing  the 
predicates  can  be  specified  and  the  central  problem  in  predicate  abstraction,  namely  what 
predicates  to  use,  is  left  unsolved.  For  the  examples  considered  in  [81],  the  authors  man¬ 
ually  pick  the  predicates.  In  contrast,  our  method  specifies  a  framework  for  what  type  of 
predicates  to  pick.  In  our  case  studies,  the  relevant  predicates  were  constructed  just  by  a 
syntactic  exploration  of  the  protocol  code. 


2.7.4  Counter  Abstraction 

Counter  Abstraction  is  an  intuitive  method  to  use  on  parameterized  systems,  and  it  has 
been  employed  by  various  researchers  in  different  contexts  [5;  28;  34;  66].  Pnueli  et 
al.  [66],  who  coined  the  term  counter  abstraction,  show  how  concurrent  systems  com¬ 
posed  of  symmetric  and  finite  state  processes  can  be  handled  automatically.  The  essential 
idea  in  counter  abstraction  is  to  have  a  counter  Ci  for  each  possible  local  state  i  of  the 
processes.  Counter  Ci  then  counts  the  number  of  processes  in  state  i  in  a  given  concrete 
system  configuration.  The  counters  are  typically  bounded  by  a  small  value  so  that  the  ab- 
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stract  system  consisting  of  the  counters  is  finite  state.  Environment  abstraction  generalizes 
counter  abstraction  since  the  abstract  descriptions  A(x)  can  serve  as  counters.  But,  in¬ 
stead  of  counting  simply  the  processes  according  to  their  local  states,  we  count  processes 
according  to  their  local  states  and  according  to  their  relationship  to  the  reference  process. 
It  is  the  latter  feature  that  lets  us  handle  systems  in  which  each  replicated  process  has 
infinite  state  space. 

In  a  symmetric  protocol,  the  identities  of  the  processes  cannot  be  used  in  the  protocol 
code.  For  instance,  a  condition  of  the  form 

for  all  j  <  i.  $(j) 

appearing  in  the  code  of  process  i  breaks  the  symmetry  because  the  process  with  id  1  will 
exhibit  different  behavior  from  process  with  id  m  >  1  (the  condition  is  trivially  true  for 
process  1  and  not  so  for  other  processes  with  ids  greater  than  1).  Most  real  life  systems  are 
not  symmetric,  that  is,  the  code  for  each  process  can  make  use  of  the  process  id.  Thus,  the 
verification  of  Szymanski’s  protocol  in  [66]  requires  manual  introduction  of  new  variables. 
Our  method  does  not  require  each  process  to  be  finite  state  nor  do  we  require  the  processes 
to  be  symmetric. 

In  [66],  the  notion  of  “all-but-one”  counter  abstraction  is  described.  The  idea  here  is 
to  apply  counter  abstraction  to  all  processes  except  one.  By  tracking  one  special  process 
in  detail,  they  are  able  to  reason  about  single  index  liveness  properties.  It  is  important  to 
note  the  following: 

•  In  a  symmetric  protocol,  any  process  can  be  chosen  as  the  special  process,  it  makes 
no  difference  in  the  abstraction. 
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•  Further,  the  other  processes  in  the  system  are  abstracted  (or  counted)  according  to 
their  local  states  alone,  not  based  on  their  relationship  to  the  special  process.  This  is 
the  crucial  difference  between  our  method  and  counter  abstraction. 

There  are  also  important  differences  in  how  we  compute  the  abstract  model  and  how 
the  abstract  model  is  computed  in  [66].  In  [66],  the  abstract  model  is  computed  precisely 
using  symbolic  techniques.  In  contrast,  we  over- approximate  the  abstract  model  by  con¬ 
sidering  each  transition  statement  of  the  protocol  code. 

Another  approach  that  uses,  among  other  things,  counter  abstraction  is  the  method 
proposed  by  Henzinger  et  al.  [45].  Like  “all-but-one”  abstraction  of  Pnueli  et  al.  [66], 
Henzinger  et  al.  also  track  one  thread  in  detail  (called  the  main  thread).  As  with  counter 
abstraction,  the  main  thread  does  not  serve  as  a  reference  process.  The  other  threads  in  the 
system  are  abstracted  independently  of  the  main  thread. 


2.8  Conclusion 


In  this  chapter  we  presented  the  mathematical  principles  underlying  environment  ab¬ 
straction.  This  abstraction  framework  is  designed  specifically  for  systems  with  replicated 
components.  Informally,  this  framework  is  built  around  the  insight  that  when  we  humans 
reason  about  systems  with  replicated  components  we  focus  on  one  particular  component 
while  considering  the  other  components  only  abstractly. 

In  this  chapter,  we  assumed  that  the  replicated  components  were  processes.  In  general 
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the  replicated  components  can  vary.  For  instance,  a  memory  bank  can  be  treated  as  a 
collection  of  identical  memory  cells.  Our  method  can  be  extended  to  all  these  instances  as 
well. 

It  is  crucial  to  distinguish  two  different  issues  that  have  been  covered  in  this  chapter: 
(i)  “what  abstract  state  space  to  consider?”  and  (ii)  “how  to  build  the  abstract  model?” 
or  rather,  “how  to  use  this  abstract  state  space  to  accomplish  verification?”.  In  answer 
to  the  first  question  we  propose  using  an  abstract  state  space  of  descriptions  A(x).  In 
answer  to  the  second  question,  we  propose  constructing,  up  front,  an  over- approximate 
abstract  model.  It  is  not  necessary  for  using  environment  abstraction  that  we  build  the 
abstract  model  up  front.  We  can  use  an  explicit  state  exploration  as  done  by  TVLA  as 
well.  However,  we  think  that  for  protocols,  which  can  usually  be  expressed  using  only  a 
few  types  of  basic  constructs,  our  way  of  building  the  abstract  model  up  front  is  the  best 
possible  choice. 

In  the  next  chapter,  we  instantiate  environment  abstraction  in  the  context  of  cache 
coherence  verification.  We  will  cover  all  the  issues  raised  in  this  chapter  from  descriptions 
to  computing  the  abstract  model. 
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Chapter  3 


Environment  Abstraction  for 
Verification  of  Cache  Coherence 
Protocols 


3.1  Introduction 


The  performance  advantages  of  multi-core  shared  memory  architectures  have  created  a 
strong  industrial  trend  towards  multi-core  designs.  Such  state-of-the-art  architectures  cru¬ 
cially  rely  on  caching  mechanisms  for  increased  performance.  The  increasing  complexity 
of  such  systems  is  reflected  in  the  intricate  cache  protocols  they  employ.  As  these  cache 
coherence  protocols  are  inherently  parameterized,  it  is  a  challenging  task  to  ensure  their 
correctness  by  automatic  verification  methods.  In  this  chapter,  we  show  how  to  use  the 
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environment  abstraction  to  verify  directory  based  cache  coherence  protocols  -  the  most 
widely  employed  class  of  cache  coherence  protocols.  We  use  this  abstraction  method  to 
verify  the  standard  safety  property  of  several  versions  of  the  German’s  protocol  and  of 
a  modified  version  of  the  Flash  protocol. 


3.1.1  Cache  Coherence  Protocols 

Caching  mechanisms  are  ubiquitous  in  modern  computer  systems.  Computer  systems 
usually  have  several  memory  banks,  each  with  different  latency.  To  reduce  the  time  needed 
to  access  data  items  and  thus  improve  the  performance,  caching  mechanisms  are  used  to 
store  frequently  accessed  data  items  in  the  fastest  available  memory  bank. 

Modem  processors  typically  come  with  several  levels  of  caches.  A  cache  is  a  small 
memory  bank  that  usually  sits  on  the  motherboard  of  a  processor.  Higher  the  physical 
distance  of  a  cache,  the  higher  the  latency  of  that  cache.  A  data  item  that  is  frequently 
used  by  the  processor  can  be  stored  in  one  of  its  caches.  When  the  data  item  is  needed 
again,  instead  of  going  all  the  way  to  the  main  memory,  the  data  item  can  be  supplied  from 
the  cache  itself. 

While  the  availability  of  such  caches  dramatically  increases  the  performance  of  a 
multi-processor  system,  care  must  be  taken  to  prevent  processors  from  accessing  data 
items  in  an  unsafe  manner.  For  instance,  two  processors  PI  and  P 2  might  both  have  a 
data  item  d  in  their  local  caches.  After  performing  some  computations  both  the  processors 
may  decide  to  write  back  their  local  values  of  d  to  the  main  memory.  If  this  activity  is 
not  coordinated  properly,  the  value  of  d  as  determined  by  one  of  the  processors  will  be 
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lost.  In  the  presence  of  multiple  data  items,  such  loss  can  lead  to  computations  that  are 
not  feasible  in  any  legal  execution  of  the  processors.  Thus,  to  coordinate  the  activities  of 
different  processors  in  a  multiple  processor  system  and  to  provide  a  consistent  view  of  the 
memory  to  all  the  processors  cache  coherence  protocols  are  used. 

There  are  broadly  two  types  of  cache  coherence  protocols,  namely  snoopy  and  di¬ 
rectory  based  protocols.  The  first  class  of  protocols  is  broadcast  based  with  no  central 
coordination.  The  second  type  of  protocols,  the  directory  based  protocols,  are  based  on 
point  to  point  communication  and  have  centralized  coordination.  In  snoopy  protocols,  all 
the  processors  (more  precisely,  their  cache  controllers)  monitor  the  activities  on  the  com¬ 
mon  system  bus.  Since  every  processor  knows  what  data  items  the  other  processors  are 
using,  cache  coherence  can  be  achieved  quite  simply.  In  snoopy  protocols,  there  is  no  cen¬ 
tralized  decision  making.  The  actions  of  the  local  caches,  which  have  full  knowledge  of 
other  caches,  are  enough  to  ensure  cache  coherence.  Snoopy  protocols  are  typically  used 
in  systems  which  have  a  small  number  of  processors. 

Directory  based  protocols,  on  the  other  hand,  use  centralized  decision  making  to  ensure 
cache  coherence.  For  each  data  item,  one  of  the  processors  is  designated  as  the  home  or 
the  directory  process.  Requests  by  the  processors  to  access  a  data  item  are  sent  to  the 
home  process  for  that  item.  The  home  process  maintains  detailed  information  about  which 
processors  are  using  the  item  and  can  respond  appropriately  to  each  request.  Directory 
protocols  are  more  widely  used  as  they  scale  better  [56]. 

A  crucial  issue  in  the  design  of  cache  protocols  is  the  speed  with  which  a  data  item  is 
delivered  to  the  requesting  process.  Depending  on  how  this  issue  is  handled,  directory  pro- 
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tocols  are  of  two  types:  lazy  and  eager  protocols.  In  lazy  protocols,  the  directory  process 
doesn’t  grant  exclusive  access  to  a  requesting  processor  until  it  has  received  acknowledge¬ 
ments  from  other  processors  in  the  system  that  were  sharing  the  data  item  and  were  sent 
invalidate  messages.  Eager  protocols,  on  the  other  hand,  do  not  wait  for  the  acknowledge¬ 
ments.  In  our  experiments,  we  considered  an  eager  version  of  the  Flash  protocol  and  a 
lazy  version  of  the  German  protocol. 

There  is  no  consensus  on  which  type  of  cache  coherence  protocols  -  snoopy  or  direc¬ 
tory  based  -  is  better.  While  snoopy  protocols  tend  to  have  lower  latency,  they  require 
totally-ordered  interconnect  with  a  broadcast  mechanism  (usually  a  bus)  connecting  all 
the  processors.  Directory  protocols  do  away  with  the  interconnect  in  exchange  for  higher 
latency.  In  an  informative  article  [56],  Martin  revisits  this  debate  from  a  verification  point 
of  view. 

There  are  multiple  correctness  issues  to  be  considered  while  designing  cache  coherence 
protocols.  The  simplest  correctness  properties  talk  about  the  way  a  single  data  item  is 
accessed  (called  coherence  properties).  For  instance,  all  cache  protocols  require  that  a 
data  item  cannot  be  held  in  exclusive  (or  dirty)  state  while  it  is  held  in  shared  state  by 
some  other  processor.  It  is  also  required  that  a  requesting  process  will  eventually  get  the 
data  item.  In  our  work,  we  have  dealt  with  correctness  properties  involving  only  one  data 
item.  Cache  properties  involving  multiple  data  items  (called  consistency  properties)  are 
usually  complex  and  very  hard  to  verify  formally.  For  example,  verifying  whether  all  the 
executions  that  a  cache  protocol  allows  are  legal  under  the  chosen  memory  consistency 
model  is  a  very  hard  problem.  While  there  has  been  some  effort  to  address  this  problem, 
it  is  far  from  being  solved  [20]. 
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In  this  chapter,  we  will  first  formalize  the  system  model  for  cache  coherence  protocols. 
Our  model  will  contain  one  non-replicated  process  (the  central  process )  representing  the 
home  processes,  and  an  unbounded  number  of  replicated  processes  (the  local  processes ) 
representing  the  caches.  The  transitions  executed  by  the  caches  are  very  simple,  whereas 
the  central  directory  can  perform  quite  complex  actions.  For  instance,  the  directory  can 
keep  pointer  variables,  which  point  to  the  caches,  and  modify  the  local  states  of  the  caches. 
We  will  describe  a  simple  language  for  writing  the  transitions  of  local  processes  and  the 
central  process.  The  constructs  used  in  this  language  ignore  the  low  level  implementa¬ 
tion  details  and  describe  the  protocol  at  an  algorithmic  level.  In  fact,  these  constructs 
correspond  to  the  way  system  designers  think  about  cache  protocols. 

We  will  then  use  the  environment  abstraction  presented  in  the  previous  chapter  to  pa- 
rameterically  verify  the  safety  property  of  cache  coherence  protocols. 

Outline 

In  Section  3.3  we  describe  a  modeling  language  that  accounts  for  the  specifics  of  cache 
coherence  protocols,  and  in  Section  3.4  we  describe  how  to  apply  environment  abstraction 
to  verify  cache  coherence  protocols.  Section  3.5  describes  a  redundancy  criterion  for  re¬ 
moving  set  variables  which  drastically  reduces  the  size  of  the  abstract  models.  Section  3.6 
presents  our  approach  to  over- approximating  the  abstract  model.  The  last  two  sections 
contain  experimental  results  and  conclusions. 

In  the  rest  of  this  chapter,  we  will,  for  the  sake  of  simplicity,  speak  of  “caches”  and  “di¬ 
rectory”  instead  of  “local  processes”  and  “central  process”  respectively.  We  will  consider 
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only  coherence  properties  involving  a  single  data  item. 


3.2  Discussion  of  Related  Work 


Parameterized  verification  of  cache  coherence  protocols  has  received  considerable  at¬ 
tention,  see  [21;  28;  29;  52;  58;  64;  67;  68]. 

The  papers  closest  to  our  approach  are  [67;  68]  and  [29].  Delzanno  and  Bultan  [29] 
that  describe  a  constraint  based  verification  method  for  handling  the  safety  and  liveness 
properties  of  German’s  protocol.  Their  approach  avoids  the  problem  of  handling  vari¬ 
ables  which  store  cache  ids  and  sets  of  cache  ids  by  exploiting  synchronization  labels  for 
actions.  But,  real  protocols  do  not  use  such  synchronizations  mechanisms,  which  are  un¬ 
suited  to  model  cache  coherence  protocols.  For  example,  when  using  such  synchronization 
labels,  staggered  reception  of  messages  by  different  caches  (during  a  broadcast  transition) 
cannot  be  modeled. 

Pong  and  DuBois  [67;  68]  developed  an  explicit  state  model  checking  method  that  uses 
a  technique  very  similar  to  counter  abstraction  to  exploit  the  symmetry  and  homogeneity 
of  cache  coherence  protocols.  They  handle  snoopy  protocols  as  well  as  directory  based 
protocols.  Note  that  neither  [67;  68]  nor  [29]  have  the  notion  of  a  reference  process.  Con¬ 
sequently,  in  contrast  to  our  approach,  they  cannot  verify  single  index  liveness  properties. 
Furthermore,  their  abstraction  explicitly  considers  the  set  variables.  In  our  abstraction,  we 
are  able  to  eliminate  the  set  variables  from  the  abstract  model,  which  drastically  reduces 
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the  size  of  the  abstract  model. 


The  compositional  method  of  McMillan  [58]  uses  compositional  reasoning  to  handle 
infinite  state  systems  including  directory  based  protocols.  This  technique,  which  requires 
user  intervention  at  various  stages,  has  been  applied  to  verify  safety  and  liveness  properties 
of  the  Flash  protocol.  The  paper  [21]  by  Chou  et  al.  presents  a  method  along  similar 
lines  that  was  used  to  verify  safety  of  Flash  and  German’s  protocol.  The  aggregated 
transactions  method  pioneered  by  Park  and  Dill  [63]  is  based  on  theorem  proving,  and  has 
been  used  to  verify  directory  based  protocols  such  as  the  Flash  protocol.  The  essential 
idea  behind  this  technique  is  to  collect  the  various  statements  in  the  protocol  code  into  a  set 
of  7-8  high  level  transactions.  The  user  has  to  provide  proofs  of  correspondence  between 
the  high  level  transactions  and  the  protocol  code. 

Pnueli  et  al.  [64]  show  how  to  verify  safety  of  German’s  cache  coherence  protocol. 
They  do  not  verify  liveness  properties  nor  have  they  handled  Flash  protocol. 

Bingham  et  al.  [9]  describe  a  method  for  verifying  infinite  state  systems  that  can  be 
modelled  as  Well  Structured  Transition  Systems  or  WSTS  systems.  WSTS  systems  are  a 
well-studied  class  of  infinite  state  systems  for  which  the  problem  of  reachability  of  error 
states  is  decidable  (subject  to  some  technicalities).  They  applied  this  method  to  Ger¬ 
man’s  protocol  and  verified  data  coherence  (that  is,  read  on  a  data  item  returns  the  last 
written  value). 
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3.3  System  Model  for  Cache  Coherence  Protocols 


Our  system  model  reflects  the  structure  of  real-life  cache  coherence  protocols.  A  typical 
cache  coherence  system  contains  several  caches,  one  of  which  is  designated  as  the  home 
cache.  The  home  cache  maintains  a  directory  and  regulates  the  access  to  the  data  items  for 
which  it  is  responsible.  Following  [64],  we  will  model  the  home  cache  as  consisting  only 
of  the  directory  and  call  it  the  directory  or  directory  process.  Since  the  number  of  caches 
in  the  system  is  not  fixed,  cache  coherence  protocols  are  classical  instances  of  parameter¬ 
ized  systems.  Note,  however,  that  the  presence  of  the  directory  in  the  system  breaks  the 
symmetry  between  the  processes.  Since  we  are  concerned  with  coherence  properties  of 
a  cache  protocol,  it  is  enough  to  consider  only  one  data  item.  Thus,  we  will  implicitly 
assume  that  there  is  only  one  data  item  in  the  system. 

In  our  formal  model,  we  consider  asynchronous  systems  consisting  of  K  caches  run¬ 
ning  the  same  program  P  and  one  directory  running  a  different  program  C.  For  given 
programs  P  and  C,  the  system  consisting  of  K  caches  and  one  directory  is  denoted  by 
V(K).  Each  cache  has  a  distinct  id  in  the  range  R  =  {1, . . . ,  K}.  As  all  caches  are  identi¬ 
cal,  their  sets  of  variables  are  also  named  identically.  When  necessary,  we  will  write  v{i) 
to  refer  to  variable  v  of  cache  i. 

The  system  V(K)  is  formally  modelled  as  Kripke  structure  (SK,  IK,  Rk,  Lk).  The 
set  of  states  Sk  is  given  by  tuples  of  the  form  (£i, ....  CK,  C),  where  each  Ct  is  the  local 
state  of  cache  i  and  C  is  the  state  of  the  central  process  C.  In  the  following  sections,  we 
will  describe  the  state  space  the  caches  and  the  central  directory.  Then,  we  will  define  the 
transition  relation  Rk  in  terms  of  the  transitions  the  caches  and  the  central  process  take. 
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3.3.1  State  Variables 


The  caches  are  essentially  finite  state  machines,  and  thus  each  cache  has  one  finite  range 
control  variable  pcL  with  range  {1, . . . ,  T}.  Since  multiple  finite  range  variables  can  al¬ 
ways  be  encoded  as  one  variable,  there  is  no  loss  of  generality.  In  our  implementation  and 
in  examples  later  in  the  chapter,  we  will,  in  fact,  tacitly  use  multiple  finite  range  variables. 

The  directory  has  three  different  kinds  of  variables,  distinguished  by  the  way  they  are 
used: 


•  The  control  variable ,  pcc,  has  finite  range  {1, . . . ,  F},  F  >  1,  and  represents  the 
control  locations  of  the  directory. 

•  The  pointer  variables,  ptr1? . . . ,  ptiy,  where  b  >  1,  are  used  to  store  the  ids  of  caches. 
Thus,  in  a  system  V(K),  the  range  of  the  pointer  variables  is  R. 

•  The  set  variables  seti, . . . ,  setc,  where  c  >  1,  are  used  to  store  sets  of  cache  ids,  and 

D 

their  range  is  the  powerset  2  . 

Example.  In  German’s  protocol,  the  variable  currclient  holds  the  id  of  the  cache  that 
the  directory  is  currently  communicating  with.  This  variable  is  naturally  modeled  as  a 
pointer  variable.  Similarly,  German’s  protocol  has  a  list  sharlist  containing  all  caches 
that  hold  the  data  item  in  a  shared  state.  This  list  is  naturally  modeled  as  a  set  variable. 

A  state  of  system  V(K)  is  a  tuple  (£i, . . . ,  Ck,  C)  where  the  £,  are  the  control  loca¬ 
tions  of  the  caches,  and  C  is  the  state  of  the  directory,.  The  state  of  the  directory,  C,  is  a 
valuation  of  the  tuple  (pcc,  ptiy, . . . ,  ptiy,  seti, . . . ,  setc). 
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We  shall  see  below  that  the  ptr  variables  are  used  solely  to  access  the  state  of  the 
caches.  That  is,  no  arithmetic  or  comparison  on  ptr  variables  is  allowed.  Similarly,  set 
variables  are  used  either  to  access  caches  or  in  membership  queries  (i.e.,  whether  a  cache 
belongs  to  the  set  or  not).  We  assume  that  all  variables  are  used  in  a  type-safe  way,  that  is, 
they  are  assigned  or  compared  only  against  values  from  their  ranges. 

The  initial  state  of  the  directory  and  the  caches  is  given  by  a  fixed  valuation  of  all 
variables. 


3.3.2  Program  Description  for  the  Caches 

We  will  describe  the  transitions  of  the  caches  and  the  central  process  using  a  few  high  level 
constructs.  Caches  have  very  simple  control  flow  structures,  as  they  can  move  only  from 
one  control  location  to  another.  We  can  describe  the  cache  transitions  using  the  following 
transitions: 


pcL  =  L\  :  goto  pcL  =  Ll2 

The  semantics  of  the  transition  is  simple:  a  cache  P(i)  in  control  location  L\  can,  at  a 
nondeterministically  chosen  timepoint,  change  its  state  variable  to  If.  The  goto  statement 
is  deterministic  in  the  sense  that  for  each  location  L\,  there  is  at  most  one  jump  goal  If. 

Note  that  the  state  of  a  cache  can  also  be  changed  by  the  directory,  see  Section  3.3.3. 
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3.3.3  Program  Description  for  the  Directory 


The  directory  can  execute  more  complex  programs  than  the  cache.  In  particular,  it  can 
execute  a 

•  simple  action  to  change  its  control  variables,  or 

•  update  action  to  update  its  pointer  or  set  variables,  or 

•  remote  action  to  change  the  state  of  a  cache  referenced  by  a  pointer. 

These  basic  actions  reflect  the  operations  used  in  a  typical  directory  based  cache  co¬ 
herence  protocol.  We  will  see  that,  of  the  above  actions,  the  update  action  and  the  remote 
action  depend  on  the  state  of  the  caches.  However,  only  the  remote  action  can  change  the 
state  of  a  cache.  Below  we  will  define  the  actions  in  more  detail. 

A  directory  transition  statement  has  the  form 

guard  :  do  actions  Ai,  A2, Ak 

where  Ai, ...  ,Ak  are  basic  actions  as  described  below,  and  guard  is  a  condition  of  the 
form  pcc  =  L  A  ^(ptr,  set).  Here,  L  is  a  directory  control  location  and  <T>(ptr,  set)  is  a 
Boolean  combination  of  expressions  of  the  form  pcjptrj  =  LL,  ptr  e  set,;,  or  set;  =  0. 

The  semantics  of  this  statement  is  as  follows: 

1.  If  guard  is  true,  then  execute  the  actions  A-^  . . . ,  Ak. 

2.  The  whole  transition,  including  the  evaluation  of  the  guard,  is  executed  atomically 
in  one  time  step  with  actions  A\, . . . ,  Ak  being  executed  in  that  order. 
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3.  We  will  assume  that  the  basic  actions  in  a  transition  do  not  conflict  with  each  other. 


In  other  words,  no  variable  should  be  modified  by  more  that  one  action.  This  implies 
that  there  is  only  one  simple  action  per  transition,  that  no  ptr  variable  is  updated  by 
more  than  one  action,  that  only  one  set  variable  is  updated,  and  that  remote  actions 
are  executed  on  different  caches. 

We  will  now  describe  the  basic  actions  in  more  detail. 

Simple  Actions  have  the  format  goto  pcc  =  Lc,  where  Lc  is  a  directory  control  location. 

The  semantics  of  this  action  is  that  the  directory  control  variable  pcc  is  set  to  Lc. 

Update  Actions  come  in  several  formats: 

o  assign  ptr,  =  ptr/  and  assign  set,  =  set,.  The  next  value  of  ptr,  is  set  to  the  current 
value  of  ptr,-. 

o  add  ptr,  to  set,  and  remove  ptr,  from  set,.  Add  or  remove  the  cache  pointed  to  by 
ptr,  from  set  set,. 

o  pick  ptr,  from  SL.  where  SL  is  a  list  of  (constant)  cache  control  locations.  The 
semantics  of  this  action  is  that  the  variable  ptr,  is  nondeterministically  made  to  point 
to  one  of  the  caches  whose  control  location  is  in  SL.  If  there  is  no  such  cache,  then 
ptr,  is  unchanged. 

Remote  Actions  have  the  form  remote  V  :  goto  pcL  =  LL,  where  LL  is  a  cache  control 

location  and  V  is  a  pointer  variable.  This  action  enforces  the  new  control  location  L  on 
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the  cache  pointed  to  by  V.  In  general,  the  remote  action  can  also  have  the  form 


remote  V  :  map 

where  map  is  a  switch  statement  of  the  form: 

switch  pcL{ 

L\ 

L\ 


} 


goto  pcL  =  L'l 
goto  pcL  =  Lg 


This  action  enforces  the  cache  pointed  to  by  V  to  execute  the  switch  statement.  The  remote 
action  is  analogously  defined  for  set  variables.  A  remote  action  for  a  set  variables  forces 
all  the  caches  in  the  set  variable  to  execute  the  switch  statement  simultaneously.  While 
German’s  protocol  does  not  require  remote  actions  on  set  variables,  Flash  protocol 
does. 

The  remote  action  is  used  to  model  the  communication  from  central  process  to  the 
local  caches.  For  example,  in  German’s  protocol,  the  central  directory  process  sends 
invalidate  message  to  all  the  caches  present  in  the  invlist  set  variable  one  cache  at  a  time. 
The  central  process  first  picks  a  cache  present  in  invlist  by  assigning  a  pointer  variable 
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temptr  1  appropriately.  Then  the  central  process  writes  an  invalid  message  to  the  incom¬ 
ing  channel,  chan2,  of  the  cache  pointed  to  by  temptr  1.  Since,  we  model  communication 
channels  as  internal  variables  of  the  caches,  the  effect  of  central  process  writing  to  chan2 
can  be  accurately  modelled  as  a  remote  action  with  the  general  switch  statement. 


3.3.4  Describing  Real-Life  Protocols 

German’s  protocol  and  the  Flash  protocol  can  be  naturally  expressed  in  our  protocol 
description  language.  These  protocols  share  a  common  basic  functionality:  when  a  cache 
requests  shared  access  to  a  data  item,  the  directory  grants  the  request  if  the  data  item  is 
not  held  in  exclusive  state  by  any  other  cache.  Otherwise,  the  directory  sends  a  message 
to  the  cache  having  exclusive  access  to  the  data  item  to  relinquish  control  over  the  data 
item.  Subsequently,  the  directory  grants  shared  access  to  the  cache  that  issued  the  re¬ 
quest.  When  a  cache  requests  exclusive  access  to  the  data  item,  the  directory  grants  the 
request  if  no  other  cache  has  any  form  of  access  to  the  data  item.  Otherwise,  the  direc¬ 
tory  sends  messages  to  all  caches  having  access  to  the  data  item  to  invalidate  their  local 
copies.  The  directory  can  either  wait  to  receive  acknowledgements  from  the  caches  ( lazy 
operating  mode)  or  grant  exclusive  access  to  the  cache  which  issued  the  request  ( eager 
operating  mode).  In  this  thesis,  we  consider  the  Flash  protocol  operating  in  eager  mode 
and  German’s  protocol  operating  in  lazy  mode. 

While  the  basic  functionality  of  many  cache  coherence  protocols  essentially  follows 
the  above  description,  there  are  a  lot  of  additional  low  level  details  that  add  to  the  com¬ 
plexity  of  a  directory  based  protocol  and  need  to  be  accounted  for  in  our  input  language. 
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In  a  typical  protocol,  the  caches  communicate  with  the  directory  process  using  dedi¬ 
cated  communication  channels.  The  caches  execute  relatively  independently  of  each  other. 
Thus,  the  simple  goto  statements  for  caches  suffice  to  model  the  transitions  of  the  caches. 
The  directory  process  usually  maintains  pointers  to  caches  and  also  sets  of  caches.  The 
pointer  and  set  variables  are  used  to  receive  and  send  messages  to  specific  recipients. 

Following  other  work  in  this  area  [29;  64],  we  assume  that  the  communication  chan¬ 
nels  between  caches  and  the  directory  are  of  length  1 .  The  communication  channels  are 
modeled  using  local  variables  of  the  caches.  Since  the  directory  can  read  and  write  to 
the  local  variables  via  the  remote  action,  the  local  variables  can  simulate  communication 
channels.  For  instance,  in  German’s  protocol  we  have  a  central  transition  statement: 

currcmd,  =  empty  A  read  =  yes  A  chanl[curr  client]  =  reqshar: 
do  actions  goto  read  =  no  A  currcmd  =  reqshar , 
remote  currclient:  goto  chanl  =  empty 

which  shows  how  the  directory  communicates  with  a  cache.  Here,  the  pointer  variable 
currclient  points  to  a  local  process,  and  chanl[curr client]  is  the  variable  that  serves  as  a 
communication  channel  from  the  cache  to  the  directory.  Note  also  that  there  is  more  than 
one  control  variable  in  the  directory,  namely,  read,  and  currcmd. 

The  above  transition  says  that  if  there  is  a  reqshar  message  in  channel  chanl,  the 
directory  process  reads  it  by  updating  the  variable  currcmd  using  the  goto  action.  After 
reading  it,  the  directory  removes  the  message  from  chanl  using  the  remote  action  which 
sets  chanl  to  empty.  Broadcast  actions  can  also  be  described  succinctly  using  remote 
actions. 

Note  that  in  our  language,  the  protocol  is  described  at  a  high  level  without  getting 
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into  implementation  details,  reflecting  the  abstraction  level  at  which  designers  think  about 
protocols.  This  approach  is  consistent  with  the  current  trend  towards  synthesis  of  low  level 
designs  from  reliable  and  easily  verifiable  high  level  designs. 

The  full  descriptions  of  the  Flash  protocol  and  German’s  protocol  are  given  in 
Section  3.9. 


3.4  Environment  Abstraction  for  Cache  Coherence  Pro¬ 
tocols 

In  this  section,  we  instantiate  environment  abstraction  for  verifying  cache  coherence  pro¬ 
tocols. 

3.4.1  Specifications  and  Labels 

Most  properties  of  interest  in  parameterized  systems  refer  to  the  control  locations',  for 
example,  typical  safety  properties  say  that  no  two  caches  can  hold  the  same  data  item  in 
exclusive  state  at  the  same  time.  Usually  we  are  interested  in  verifying  such  properties  for 
each  cache  in  the  system,  not  for  a  specific  cache.  In  this  chapter,  we  will  consider  the 
two-indexed  safety  property 

Vx,  y.x  y  A  pc[x]  =  crit  ->(pc[?/]  =  crit) 

This  can  be  equivalently  written  as  a  single  index  property 

Vx.(pc[x]  =  crit  =>-  -i(crit  e  env  (®))) 
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To  handle  such  specifications,  the  set  of  labels  L  we  use  will  have  labels  of  two  types: 


•  pcL [re]  =  L,  and 

•  L  e  env(x). 

3.4.2  Abstract  Model 

As  mentioned  previously,  we  will  represent  abstract  descriptions  as  tuples  as  this  simplifies 
the  presentation  significantly.  The  abstract  states  will  contain  information  about 

•  the  internal  state  of  the  reference  cache 

•  the  internal  states  that  occur  in  other  caches,  and 

•  the  internal  state  of  the  directory. 

Formally,  an  abstract  state  is  a  tuple 

s=  (pcL,ei,...,eT  ;  pcc,  ptr  1? . . .  ptr  b,  seTi, . . . ,  seTc) 

whose  semantics  we  will  explain  in  the  following  paragraphs. 

First,  and  importantly,  s  describes  the  system  from  the  viewpoint  of  the  reference 
cache:  pcL  is  the  control  location  of  the  reference  cache  and  each  bit  et  tells  whether 
some  other  cache  is  in  control  location  i.  Moreover,  s  contains  information  about  the  di¬ 
rectory:  pcc  is  the  control  location  of  the  directory,  and  ptr ,  and  set ,  are  abstractions  of 
the  pointers  and  sets  of  the  directory. 
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Thus,  the  variables  have  the  following  ranges:  pcL  G  {1, . . .  ,  T}  is  a  cache  control 
location,  pcc  G  {1, . . . ,  F}  is  a  directory  control  location,  and  the  e,  are  Boolean  values 
representing  the  “environments”.  The  bit  e*  has  value  1  if  there  exists  a  cache  y  different 
from  x  that  is  in  control  location  i,  i.e.,  “the  environment  of  x  contains  a  cache  in  control 
location  i”.  This  is  expressed  by  the  quantified  formula 

£i{x)  =  3 y  f  z.pcj y]  =  i 

which  we  call  the  environment  predicate.  Note  that  an  environment  predicate  8l(x)  and 
its  corresponding  bit  in  the  abstract  state  tell  us  if  the  atomic  property  L  €  env(a:j  holds 
true  in  a  state. 

Concerning  the  pointers,  it  is  important  to  note  that  in  the  abstract  model,  a  pointer 
cannot  refer  to  a  cache,  but  only  to  an  abstracted  cache,  i.e.,  an  environment  or  the  refer¬ 
ence  cache  itself.  Thus,  we  introduce  the  set  {ref}  U  {1, . . . ,  T}  of  abstract  locations.  The 
abstract  locations  are  the  possible  values  for  the  pointers  in  the  abstract  model.  An  abstract 
pointer  value  i  G  {1, . . . ,  T}  means  that  the  pointer  refers  to  a  cache  in  control  state  i, 
and  an  abstract  pointer  value  ref  means  that  the  pointer  refers  to  the  reference  cache. 

Analogously,  the  abstract  set  variables  set  j  range  over  the  powerset  2{1,---T}u{ref}  of 
the  abstract  locations. 

Definition  3.4.1.  Let  s  be  a  concrete  state  in  a  concrete  system  V(K),  and  consider  a 
cache  p  in  V(K).  Then  s  is  the  abstraction  of  state  s  induced  by  cache  p,  in  symbols 

ap(s)  =  (pcL,ei  ,...,eT  :  pcc,  ptr  1; . . .  ptr  6,seTi, . . .  ,seTc) 
if  the  following  conditions  hold: 
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1.  In  state  s,  cache  p  is  in  control  location  pcL,  i.e., 

s  |=  PCL  =  pcL[p]. 

“The  reference  cache  is  in  control  location  pcL.” 

2.  Each  et  is  the  truth  value  of  the  environment  predicate  Sfx)  for  cache  p,  i.e., 

s\=3y  ^  p.pcL[y]  =  i  iff  e*  =  1. 

“ The  environment  contains  a  cache  in  control  location  i.  ” 


3.  The  directory  is  in  control  location  pcc,  i.e., 

s  H  Pcc  =  PCC- 

“The  directory  is  in  control  location  pcc.” 


4.  Each  pointer  ptr ,  has  value  absfptr,),  where  absfptr,)  is  the  abstract  location  pointed 
to  by  ptrt,  i.e., 

( 

ref  if  s  \=  pbj  =  p 

pcLlptrJ  otherwise 

“The  i-th  pointer  points  to  the  abstract  location  ptr ” 


abs(ptrj)  = 


5.  The  sets  set  t  generalize  the  pointers  in  the  natural  way,  i.e., 

set  i  =  (abs(g)  :  q  €  set*}. 

“The  i-th  set  variable  points  to  the  set  set  j  of  abstract  locations.” 
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Before  we  can  apply  environment  abstraction,  we  have  to  prove  that  the  set  of  abstract 
states  SA  and  the  set  of  labels  L  satisfy  the  coverage  and  congruence  conditions. 

Proposition  1.  For  the  abstraction  mapping  a  given  above,  the  set  of  abstract  states  SA 
satisfies  the  coverage  condition. 

Proof.  Our  abstract  state  space  SA  consists  of  all  possible  tuples  of  the  form 
(pcL,  e1, . . . ,  eT  ;  pcc,  ptr  1; . . .  ptr  b,  set  i, . . . ,  set  c).  This  fact  combined  with  our  ab¬ 
straction  mapping  defined  above  ensure  that  no  matter  what  concrete  state  s  and  what 
process  c  we  consider  ac(s)  G  SA.  Thus,  the  coverage  condition  is  trivially  satisfied  by 
our  abstract  state  space.  □ 

Proposition  2.  For  every  label  l(x )  G  L  and  every  abstract  state 
s  =  (pcL,  ei, . . . ,  eT  ;  pcc,  ptr  r, ... .  ptr  b,  set  i, ... ,  set  c),  the  abstract  description  A(A) 
corresponding  to  s  either  implies  l{x)  or  its  negation.  That  is,  A  (A)  l(x)  or  A(x) 

-nl(x) 

Proof.  Clearly,  if  the  label  l(x)  is  of  the  form  pc  [a;]  =  L,  then  the  abstract  state  A  (A) 
either  implies  l(x)  or  its  negation. 

In  case  l{x)  is  of  the  form  L  G  env(A),  then  again  A(x)  implies  l(x)  or  its  negation. 
This  follows  easily  from  the  fact  that  each  er  indicates  whether  or  not  there  is  an  environ¬ 
ment  process  with  control  location  i.  If  the  bit  corresponding  to  control  location  L  is  1 
in  the  tuple  corresponding  to  A  (A)  then  A(x)  l(x).  Otherwise,  A  (A)  -t l(x).  □ 

The  abstract  model  VA  =  ( SA ,  IA)  RA ,  LA )  is  defined  as  in  Section  2.2.  The  following 
corollary  is  then  just  an  instantiation  of  Theorem  2.2.4 
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Corollary  2  (Soundness  of  Abstraction).  Let  'P(N)  be  a  parameterized  cache  coherence 
system  and  VA.  Consider  a  control  specification  If  VA  (=  (f>(x)  then  'P(N)  |= 

\/x.(f>(x). 


From  Environment  Bits  to  Counters 


To  keep  the  presentation  simple  we  have  represented  the  variables  e%  as  bits  which 
indicate  whether  there  exists  a  cache  in  control  location  i.  To  make  the  abstraction  more 
precise,  the  e,  can  be  easily  generalized  to  counters  of  range,  e.g.,  (0, 1,  2},  where  2  is 
called  the  counter  threshold.  Then  e*  =  0  means  that  there  is  no  cache  y  ^  x  in  control 
location  i,  et  =  1  means  that  there  is  exactly  one  cache  y  ^  x  in  control  location  i,  and 
e,  =  2  means  that  at  least  two  caches  y  ^  x  arc  in  control  location  i.  All  results  in 
this  chapter  can  be  readily  generalized  to  counter  thresholds,  and  our  tool  also  supports 
arbitrary  counter  thresholds. 


3.5  Optimizations  to  Reduce  the  Abstract  State  Space 
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3.5.1  Eliminating  Unreachable  Environments 


The  abstract  model  as  described  so  far  has  a  environment  bit  e  f  for  each  possible  local  state 
L  of  the  caches.  It  may  be  the  case  that  not  all  possible  local  states  are  indeed  reachable  and 
the  corresponding  abstract  bits  (or  counters),  which  are  redundant,  can  be  eliminated.  Our 
experiments  in  fact  indicate  that  this  kind  of  optimization  achieves  significant  reduction  in 
the  size  of  the  abstract  model. 

Finding  the  local  reachable  states  can  be  done  as  follows.  First  note  that  the  local 
state  of  a  cache  can  change  in  two  ways:  1)  the  cache  executes  a  local  goto  action,  or  2) 
the  central  process  changes  the  state  of  the  cache  using  a  remote  action.  Considering  the 
former  case,  if  a  local  state  si  is  reachable  and  there  is  a  local  transition 


pcL  =  si  :  goto  pcL  =  s2 


then  local  state  s2  is  reachable  as  well.  Thus,  we  add  a  transition  (si,  s2)  to  a  reachability 
relation  R  (the  reachability  relation  R  is  initially  empty). 

For  the  latter  case,  consider  a  remote  action: 


remote  V  :  map 


where  map  is  a  switch  statement  of  the  form 
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switch  pcL{ 


L\  :  goto  pcL  =  V( 

L\  :  goto  pcL  =  LL2 

} 

Here  V  can  be  a  pointer  variable  or  a  set  variable.  In  case  V  is  a  pointer  variable,  we 
will  say  V  can  point  to  a  local  state  s  if  a  cache  in  state  s  can  be  pointed  to  by  V.  Similarly, 
if  V  is  a  set  variable,  we  will  say  V  can  point  to  a  local  state  s  if  a  cache  in  state  s  can 
belong  to  the  set  V. 

Now,  if  V  can  point  to  local  state  s\  =  L\  and  s\  is  a  reachable  local  state  then  the 
local  state  s2  =  V(  is  also  reachable.  Thus,  we  add  (si,  s2)  to  R  as  well.  By  syntactically 
examining  the  protocol  code,  we  can  determine  an  over-approximation  of  all  the  local 
states  that  V  can  point  to,  as  described  below. 

First  consider  the  case  where  V  is  a  pointer  variable.  Suppose  V  is  the  pointer  variable 
ptr,  and  the  central  process  assigns  V  a  value  using  an  action  of  the  form 

pick  ptiv  from  SL. 

The  pointer  V  =  ptr^  can  point  to  any  location  in  SL.  Finding  the  union  of  5L’s  from 
all  actions  that  modify  V  gives  us  an  over-approximation  of  the  set  of  all  caches  locations 
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that  V  can  point  to.  Call  this  set  of  locations  S.  For  every,  s  G  S'  we  add  (s,  s'),  where  s' 
is  the  location  that  s  is  mapped  to  by  map,  to  the  reachability  relation  R. 

In  case  V  is  a  set  variable  the  over-approximation  of  the  set  of  location  V  can  point  to 
is  computed  as  in  Remark  8. 

Once  we  have  R,  an  over- approximation  to  the  set  of  reachable  local  states  is  given 
by  f?*(init)  where  init  is  the  initial  state  of  the  caches.  It  is  enough  to  have  counters 
corresponding  to  only  these  reachable  locations. 


3.5.2  Redundancy  of  the  Abstract  Set  Variables 

In  this  section  we  will  describe  how  the  set  variables  can  be  eliminated  from  many  real 
protocols  including  German’s  protocol  and  the  Flash  protocol  by  a  straightforward 
program  analysis.  In  the  following  sections,  we  can  therefore  assume  that  no  set  variables 
are  present.  The  evident  motivation  to  eliminate  the  set  variables  is  state  explosion.  Since 
each  concrete  set  variable  gives  rise  to  an  abstract  set  variable  with  domain  2^1,  -’T,re^,  the 
abstract  model  may  become  prohibitively  large. 

Our  method  is  based  on  the  observation  that  in  many  real-life  protocols,  the  following 
pattern  occurs:  whenever  a  cache  is  added  to  a  set  by  an  add  action,  then  the  same  tran¬ 
sition  also  contains  a  remote  action  which  determines  the  control  location  of  the  cache 
(that  is,  when  an  add  ptr,  to  set,  action  occurs  a  remote  ptr,  ...  action  occurs  as  well).  In 
practice,  this  means  that  whenever  a  cache  is  added  to  a  list,  it  also  receives  a  message. 
Similarly,  each  remove  action  is  also  accompanied  by  a  remote  action.  Set  variables  fol¬ 
lowing  this  pattern  are  in  fact  often  redundant,  that  is,  conditions  involving  sets  can  be 
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replaced  by  equivalent  conditions  on  the  local  states  of  the  caches.  We  will  now  describe 
how  to  determine  if  a  set  is  redundant. 

Let  us  fix  a  set  variable  set,.  Then  we  can  partition  the  statements  in  the  program  D 
of  the  directory  into  three  sets: 

•  Tj”  is  the  set  of  remote  actions  which  occur  together  with  an  action  of  the  form 

add  ptr,  to  set,. 

•  T°ut  is  the  set  of  remote  actions  which  occur  together  with  an  action  of  the  form 

remove  ptr,  from  set,. 

•  The  remaining  remote  actions  in  the  program  are  collected  in  the  set  TJesi. 

Using  these  three  sets  TJr\  T°ut  and  TJest,  we  will  compute  three  sets  of  cache  states 
RJ1,  /i'J"1  ,  RJest.  Intuitively,  RJ1  will  be  the  set  of  all  states  that  a  cache  can  have  while 
it  is  a  member  of  set,.  Similarly,  R'jut  contains  all  states  that  occur  in  caches  that  are  not 
members  of  set,  . 

Given  a  set  of  cache  states  S,  the  set  r(S)  is  the  set  of  all  states  reachable  from  states 
in  S  by  local  transitions  (i.e.,  goto’s  in  the  program  of  the  cache)  and  by  remote  actions  in 
TJest.  Note  that  for  a  given  set  S,  r(S)  can  be  obtained  by  a  simple  syntactic  computation 
on  the  program.  With  this  notation,  we  can  easily  describe  RJ1,  R°ut,  and  Rr-est. 

•  Rjest  is  the  set  of  cache  states  reachable  from  the  initial  cache  states,  i.e.,  Rrjest  = 
r(Iinit)- 
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•  RJ  is  computed  as  follows:  We  collect  all  jump  goals  of  remote  1  actions  in  TJ 
into  a  set  Iin.  Then  Ft™  is  the  set  of  cache  states  reachable  from  Iin,  i.e.,  r(Iin). 

•  R°ut  is  computed  analogously  to  RJ,  with  Iin  replaced  by  Iont,  the  set  of  jump  goals 
in  T°ut. 

If  the  sets  RJst,  and  R°ut  do  not  share  any  common  elements  with  RJ.  then  the  vari¬ 
able  setj  is  redundant  in  the  sense  of  the  following  theorem: 

Theorem  3.5.1.  Assume  that  RJst  fl  RJ  =  0  and  R°ut  fl  RJ  =  0,  and  consider  a  global 
state  s  of  a  concrete  system  V(  I\  )  with  a  process  p.  Then 

s  \=  p  e  setj  iff  s  \=  pc, _[p\  e  RJ1, 

i.e.,  process  p  is  contained  in  setj  iff  its  control  location  is  in  RJ1. 

Proof.  Consider  first  the  sets  RJst  and  RJ1.  Since  RJst  fl  RJ  =  0  (that  is,  these  two  sets 
are  mutually  exclusive),  a  process  can  have  state  from  RJ  only  if  some  central  transition 
(of  the  directory)  adds  it  to  the  variable  setj.  Recall  that  we  assumed  that  a  process  is  put 
on  a  list  simultaneously  with  being  sent  a  message. 

Further,  since  RJ  and  R°ut  are  mutually  exclusive,  i.e.,  RJ1  fl  RJ  =  0,  a  process  with 
a  state  in  RJ  must  belong  to  the  set  variable  setj.  Thus,  a  process  belongs  to  setj  if  and 
only  if  its  state  is  in  RJ.  □ 

'Jump  goals  of  a  remote  action  are  simply  the  control  locations  appearing  after  the  goto’s  in  the  remote 
action. 
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Remark  8.  Note  that,  for  the  optimization  presented  in  the  previous  section,  an  over¬ 
approximation  to  the  local  states  that  set,  can  point  to  is  given  by  Ft1-1. 

In  the  following  sections  we  will  assume  that  all  the  set  variables  appearing  in  a  proto¬ 
col  are  redundant  according  to  the  criterion  presented  in  this  section. 


3.6  Computing  the  Abstract  Model 

In  this  section  we  describe  how  to  extract  an  overapproximation  of  the  abstract  model 
VA  from  the  program  text.  The  main  challenge  arises  from  the  fact  that  there  are  infinite 
number  of  concrete  systems  to  consider.  To  solve  this  problem,  we  consider  each  transition 
statement  of  the  program  separately  and  over-approximate  the  set  of  abstract  transitions  it 
can  lead  to.  This  over-approximation  can  be  expressed  by  an  invariant  on  the  current  state 
and  next  state  variables.  The  disjunction  of  all  these  invariants  is  the  abstract  transition 
relation.  To  keep  the  presentation  simple,  we  will  assume  that  set  variables  have  been 
removed  using  the  redundancy  criteria  presented  previously. 

The  abstract  transition  relation  RA  is  computed  as  a  series  of  transition  invariants  be¬ 
tween  current  abstract  state  s  and  the  next  abstract  state  s'.  We  consider  each  transition 
statement  t  appearing  in  the  protocol  code  and  find  out  what  abstract  transitions  it  can 
lead  out.  The  set  of  abstract  transitions  corresponding  to  a  concrete  transition  statement  is 
described  by  a  transition  invariant  /(f).  The  abstract  transition  relation  RA  is  then  given 
by 

\/m 

t 
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We  first  consider  the  case  where  t  is  a  local  transition  statement  of  a  cache  and  later 


consider  the  more  complicated  case  where  t  is  a  central  transition  statement. 


3.6.1  Cache  Transitions 


Recall  that  caches  can  only  make  simple  transitions  t  of  the  form 

pcL  =  L\  :  goto  pcL  =  Ll2. 

This  transition  can  be  made  either  (i)  by  the  reference  cache  or  (ii)  by  one  of  the  environ¬ 
ment  caches. 

We  will  now  give  conditions  when  to  include  an  abstract  transition  from 
s  =  (pcL,ei,...3eT,pcc,ptr ptr6)  to 

s'  =  (pc'L,  e'l3 . . . ,  e'T,  pc^,  ptr  . . . ,  ptr  b)  corresponding  to  the  transition  statement  t. 

Case  (i):  Transition  by  reference  cache.  The  local  transition  t  is  executed  by  the 
reference  case.  In  this  case,  we  require  that 

pcL  =  L\  A  pcL'  =  Ll2  (3.1) 

and  all  other  variables  are  the  same  in  s  and  s'.  Note  that  no  abstract  pointers  of  the 
directory  need  to  be  changed  because  the  abstract  pointers  have  a  special  value  ref  for  the 
reference  cache. 

Case  (ii):  Transition  by  cache  in  environment.  The  local  transition  t  is  executed  by  an 
environment  cache.  In  this  case,  we  have  the  obvious  condition  that  there  is  a  cache  in 
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state  L\  before  the  transition,  and  also  a  cache  in  L\  after  the  transition: 


eLL  =  1  A  e'LL  =  I-  (3.2) 

Moreover,  we  have  to  make  sure  that  the  pointers  of  the  directory  are  changed  in  accor¬ 
dance  with  the  transition.  Let  if  0  then  a  else  (3  denote  the  formula  (0  A  a)  V  (->0  A  (3). 
Then,  looping  over  all  pointer  variables  ptrx  to  ptr6,  we  include  the  condition  below,  which 
we  denote  by  A(Li,  Lf) 


/\if  ptr ,  0  L\  then  ptr  i  =  ptr '  else  { 

1  <i<b 

if  e'LL  =  0  then  ptr  ■  =  L\  else  ptr  \  e  {L\,  LL2}}. 

Intuitively,  A(Z0,  IX)  expresses  the  following:  if  the  pointer  does  not  point  at  L\,  then 
it  remains  unchanged.  Otherwise,  one  of  two  things  can  happen  after  the  transition.  First, 
if  there  is  no  cache  left  in  location  L\  i.e.,  e'Lt_  =  0,  then  the  cache  referred  to  by  the  pointer 
must  have  moved,  and  thus,  the  pointer  has  to  be  updated  to  point  to  L\.  Second,  if  a  cache 
is  left  in  location  L\,  then  it  is  not  clear  which  cache  moved,  and  we  over- approximate. 
Again,  all  other  variables  are  the  same  in  s  and  s'. 

The  abstract  invariant  / (t )  corresponding  to  the  transition  statement  t  is  given  by  the 
disjunction  of  3.1  and  3.2. 

Lemma  3.6.1.  Let  s,  s'  be  two  states  of  a  concrete  system  V(  I\  ).  Let  there  be  a  transition 
from  s  to  s'  with  process  c  executing  a  local  transition.  Then  the  abstract  states  ac(s)  and 
ac(s')  satisfy  the  invariant  described  by  I(t). 

Proof.  The  proof  of  this  lemma  follows  simply  from  the  way  we  constructed  /(f).  □ 
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3.6.2  Directory  Transitions 


Consider  now  the  case  where  the  transition  statement  t  is  a  directory  transition.  Recall 
that  the  directory  transitions  have  the  form 

pcc  —  L  A  <f>(ptr,  set)  :  do  actions  A1: ..,  Ak. 

Each  directory  transition  t  will  be  translated  into  a  condition 

pcc  =  L  A  l>  A  lAl  A  . .  .  lAk  A  7 Z 

where  the  XAi  are  the  abstract  conditions  corresponding  to  the  actions  A,,  and  7 Z  constrains 
all  the  abstract  variables  not  appearing  elsewhere  to  be  the  same  in  s  and  s'. 

We  will  first  show  how  to  translate  each  basic  action  At  into  a  condition  XAi . 

•  For  the  simple  action  goto  Lc  we  obtain  the  natural  condition  pc^  =  Lc. 

•  For  the  update  action  assign  ptrx  =  ptr2  we  obtain  the  condition  ptr  \  —  ptr  2. 

•  For  the  update  action  pick  ptr  from  5L  we  obtain  the  condition 

(pcL  e5LA  ptr  =  ref)  V  (e3  =  1  A  j  e  SL  A  ptr  =  j) 

V(pcL  ^  SLA/\jesL  e3  =  0  A  ptr 7  =  ptr). 

Intuitively,  if  the  reference  process  has  a  control  location  from  the  set  SL  then,  in 
the  new  state,  ptr  can  point  to  the  reference  process.  Thus,  we  have  the  disjunct 
pcL  e  SL  A  ptr  =  ref.  Alternatively,  some  environment  process  might  have  a 
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control  location  from  the  set  SL  and  the  pointer  variable  can  point  to  it  in  the  next 
state.  Thus,  we  have  the  disjunct  ej  —  1  A  j  e  <SL  A  ptr  =  j.  Lastly,  it  is  possible 
that  none  of  the  caches  have  control  locations  from  the  set  SL.  In  this  case,  the 
value  of  the  pointer  variable  does  not  change.  Hence  we  have  the  disjunct  pcL  ^ 

SL  A  AjesL  e3  —  0  A  ptr  =  ptr . 

•  For  the  remote  action  remote  ptr  :  goto  pcL  =  LL  we  obtain  the  condition 

(ptr  =  ref  A  pc'L  =  LL )  (3.3) 

V 

\J  (ptr  =  L  A  ptr'  =  LL  A  e'LL  =  1  A  Aptr(L, LL))  (3.4) 

1  <L<T 

where  Ap^r(L,  LL )  is  defined  as 

A  if  pA  A  L  then  ptr ,  =  ptr  \  else  { 
i<»<6,  ptr^ptr 

if  e'L  =  0  then  ptr  ■  =  LL  else  ptr  ■  e  {L,  LL}  }. 

Note  that  Ap {r(L,LL)  is  similar  to  A(L,LL)  defined  in  Section  3.6.1  except  that 
pointer  ptr  is  left  unchaned. 

The  explanation  for  this  abstract  transition  is  quite  simple.  If  the  pointer  ptr,  which  is 
used  in  the  remote  action,  points  to  the  reference  process,  then  the  control  location 
of  the  reference  process  is  changed  to  LL.  Thus,  we  have  the  disjunct  (ptr  =  ref  A 
PCl  =  LL )  shown  in  Equation  3.3. 

To  understand  the  second  disjunct,  shown  in  Equation  3.4,  consider  the  case  where 
ptr  points  to  an  environment  process.  Suppose  the  environment  process  is  in  envi¬ 
ronment  eL,  that  is,  ptr  =  L.  Then  the  following  hold: 
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-  In  the  next  state,  the  pointer  variable  points  to  a  process  in  environment  eLt 
because  the  new  state  of  the  cache  pointed  to  by  ptr  is  LL.  Thus,  we  have  the 
condition  ptr '  =  LL 

-  In  the  next  state,  the  environment  eLi  is  non-empty,  that  is,  e'jL  =  1.  The 
environment  eL  could  be  0  or  1  in  the  next  state. 

-  Since  a  process  moves  from  environment  to  eLi_  pointer  variables  other  than 
ptr  must  be  updated  according  to  the  condition  Ap^r(L,  LL) 

Putting  all  the  above  together,  we  have  the  condition 

(ptr  =  L  A  ptr '  =  LL  A  e'Ll  =  1  A  Aptr(L,  LL )). 

The  case  where  the  remote  action  is  of  the  more  general  form  with  map  involving 
set  variables  is  similar  to  the  case  described  above. 

Remark  9.  Since  the  set  variables  are  redundant,  add  and  remove  actions  are  irrelevant 
for  the  construction  of  the  abstract  model. 

Assuming  that  the  set  variables  are  redundant  in  the  sense  of  Section  3.5,  the  abstrac¬ 
tion  <f>  of  the  condition  $(set,  ptr)  is  obtained  by  abstracting  each  atomic  subformula: 

•  pcjptrj  =  LL  is  abstracted  into  (ptr  i  =  ref  A  pcL  =  LL)  V  ptr  i  =  LL. 

•  ptr,  G  set;  is  abstracted  into  (ptr ,  =  ref  A  pcL  G  R™)  V  (ptr ,  ^  ref  A  ptr ,  G  /?)")• 

•  set  ;  =  0  is  abstracted  into  pcL  ^  R'f  A  /\,e  es  =  0.  In  other  words,  no  cache 
should  be  in  a  state  from  /?'" ;  hence  pcL  (j  RJ1,  and  all  counters  corresponding  to 
states  in  RJ1  must  be  0. 
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Lemma  3.6.2.  Let  s.  s'  be  two  states  of  a  concrete  system  V(K).  Let  there  be  a  transition 
from  s  to  s'  with  the  directory  process  executing  the  statement  t.  Then  the  abstract  states 
oc(s)  and  ac(s')  for  any  process  c  G  [1.  .K]  together  satisfy  the  transition  invariant  I (t). 

Proof  The  proof  of  this  lemma  follows  simply  from  the  way  we  constructed  I{t).  □ 


3.7  Experiments 

German’s  cache  coherence  protocol  [44;  66]  and  Flash  cache  coherence  protocol  [63] 
are  the  two  most  widely  studied  cache  coherence  protocols.  We  applied  our  abstraction 
technique  to  several  versions,  including  the  standard,  correct  version,  of  the  German’s 
protocol  and  a  simplified  version  of  the  Flash  protocol. 

German’s  protocol,  which  operates  in  lazy  mode,  has  two  set  variables  sharlist  and 
invlist.  Whenever  a  cache  enters  a  shared  state  it  is  added  to  sharlist.  The  variable  sharlist 
is  redundant  according  to  the  criterion  in  Section  3.5.  The  variable  invlist  is  used  to  send 
invalidate  messages  to  caches  which  are  in  a  shared  state.  Initially,  invlist  is  set  equal  to 
sharlist.  When  an  invalidate  message  is  sent  to  a  cache  in  invlist ,  it  is  removed  from  invlist. 
While  invlist  is  not  redundant  according  to  the  criterion  of  Section  3.5,  a  simple  change 
makes  our  criterion  applicable:  instead  of  initializing  invlist  by  assigning  sharlist  to  it,  we 
can  add  a  cache  to  invlist  whenever  it  is  added  to  sharlist.  This  simple  change  makes  the 
set  variable  invlist  redundant,  too.  All  the  different  versions  of  the  German’s  protocol 
that  we  verified  had  this  modification  2 . 

Alternatively,  we  can  also  create  a  stronger  redundancy  criterion  for  set  variables,  which  will  ensure 
that  invlist  is  redundant  without  any  modification.  But,  the  modification  we  introduced  is  minor  and  does 
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In  addition  to  verifying  the  standard  correct  version  of  German’s  protocol,  we  also 
tried  our  method  on  buggy  versions  of  German’s  protocol  including  one  supplied  by 
Steve  German  [44].  These  buggy  versions  of  the  standard  German’s  protocol,  referred 
to  as  Buggy  1  and  Buggy  2,  are  described  in  the  last  section  of  this  chapter.  In  addition, 
we  also  applied  our  method  to  a  variant  of  German’s  protocol  which  has  four  channels, 
instead  of  the  usual  three  channels.  We  will  refer  to  this  version  as  German  4-Chan. 

For  the  Flash  protocol,  we  eliminated  the  local  pointer  variables  from  the  caches. 
These  local  pointers  are  used  to  handle  the  three-hop  case  where  the  directory  forwards  the 
id  of  the  cache  requesting  exclusive  access  to  the  cache  already  holding  that  data  item  in  an 
exclusive  state.  For  the  three-hop  case,  we  exploit  the  fact  that  at  any  point,  for  a  given  data 
item,  there  can  be  only  one  three-hop  transaction  going  on.  Thus,  to  reduce  the  state  space, 
instead  of  storing  a  pointer  at  each  cache,  we  store  one  pointer  in  the  central  directory. 
Hence,  we  can  model  the  three-hop  transaction  as  a  remote  action  of  the  directory  without 
changing  the  semantics  of  the  three-hop  transaction.  While  the  modification  in  this  case  are 
significant,  the  resultant  protocol  is  still  quite  complicated  and  retains  enough  similarity  to 
the  original  protocol  to  justify  calling  it  a  variation  of  the  Flash  protocol. 

The  safety  property  considered  for  all  the  protocols  was 

Vx.AG  (pcL  [x]  =  excl  (excl  ^  env(a;)  A  shar  ^  env(x)) 

i.e.,  if  cache  x  holds  the  data  item  exclusively  (pcL[.x]  =  excl)  then  no  other  cache  can  hold 
the  data  item  in  shared  or  exclusive  state.  The  results  of  our  experiments  are  described 
below. 

not  change  the  protocol  much. 
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Standard  German’s  protocol.  We  first  applied  our  method  to  the  standard,  correct 
version  of  German’s  protocol.  We  did  not  use  the  optimization  to  eliminate  the  counters 
for  unreachable  local  states.  For  this  unoptimized  version,  Cadence  SMV  took  about  3 
hours  (11400  seconds)  to  verify  the  safety  property.  We  then  applied  the  optimization 
to  eliminate  the  counters  corresponding  to  unreachable  local  states.  Instead  of  writing  a 
procedure  to  find  the  unreachable  states,  we  supplied  a  list  of  unreachable  local  states  to 
the  abstraction  program  manually  as  it  is  easy  to  figure  out  manually  what  local  states  are 
unreachable.  For  instance,  for  German’s  protocol,  it  is  easy  to  see  that  if  the  outgoing 
channel  chan3  is  carrying  an  invack  message  then  the  cache  state  must  be  invalid.  While 
the  list  of  states  we  supplied  may  be  not  exhaustive,  it  still  gives  significant  reduction  in  the 
abstract  state  space.  With  this  optimization,  SMV  takes  about  5  minutes  to  complete  the 
verification.  This  running  time  compares  favorably  with  other  verification  efforts  involving 
German’s  protocol,  see  for  instance  [3]. 

Version  Buggy  1.  In  the  Buggy  1  version,  after  the  directory  grants  exclusive  access 
to  a  cache,  it  fails  to  set  the  grantexcl  variable  to  true.  Thus,  when  another  cache  requests 
shared  access,  it  gets  the  access  even  though  the  first  cache  holds  it  in  exclusive  state.  We 
applied  our  abstraction  (without  the  optimization  to  eliminate  counters  corresponding  to 
unreachable  states)  and  applied  Cadence  SMV’s  Bounded  Model  Checker.  BMC  takes 
around  15  mins  to  find  the  bug  at  depth  12  (that  is,  the  bug  is  reached  after  12  transitions 
have  been  executed  by  the  cache  coherence  system). 

Version  Buggy  2.  In  the  Buggy  2  version,  the  directory  grants  a  shared  request  even 
if  grantexcl  variable  is  true.  As  with  the  previous  version,  we  constructed  the  abstract 
model  without  using  the  optimization  to  remove  counters  for  unreachable  states.  BMC 
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again  takes  under  15  mins  to  find  the  bug  at  depth  12. 

German  4-Chan.  In  this  variant  of  German’s  protocol,  there  are  four  channels 
instead  of  the  usual  three  channels.  In  specific,  instead  of  just  one  incoming  channel,  there 
are  two  incoming  channels,  chan2  and  chanA,  for  every  cache.  In  the  original  version, 
the  single  incoming  channel  carries  all  three  types  of  messages:  grantshar,  grantexcl 
and  invalid.  In  the  four  channel  version,  one  of  the  incoming  channels,  chan2  carries 
grantshar  and  grantexcl  messages  while  the  other  one,  chanA,  carries  invalid  message. 
Having  two  incoming  channels  leads  to  the  following  subtle  bug:  cache  1  requests  a  shared 
access,  and  while  this  is  being  processed,  it  sends  out  another  request.  The  first  request  is 
honored  and  cache  1  gets  shared  access  (while  the  other  request  for  shared  access  is  still 
pending).  Now  the  central  process  reads  the  second  request  from  cache  1,  and  sends  it 
another  grantshar  message  on  chan2. 

Immediately  after  this,  another  cache,  say  cache  2,  requests  exclusive  access.  Before 
granting  exclusive  access  to  cache  2,  the  central  process  sends  out  an  invalidate  message  to 
all  caches  with  shared  access,  including  cache  1  on  the  second  incoming  channel  chanA. 
Cache  1  reads  the  invalid  message  on  chanA  (while  chan2  still  has  the  grantshar  mes¬ 
sage)  and  transitions  to  invalid  state  and  sends  an  acknowledgement  to  the  central  process 
(on  chan?>).  Once  the  central  process  sees  all  the  acknowledgements,  it  grants  exclusive 
access  to  cache  2.  But,  the  grantshar  message  is  still  present  in  chan2  of  cache  1  and  this 
leads  cache  1  to  transition  to  a  shared  state.  Thus,  cache  1  ends  with  shared  access  while 
cache  2  still  has  exclusive  access. 

We  applied  our  abstraction  method  (with  both  the  optimizations  described  in  Sec- 
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tion  3.5)  and  used  a  BDD  based  model  checker  to  find  the  bug.  It  took  SMV  7  mins 
to  find  the  bug  at  depth  15.  BMC  runs  out  of  memory  at  depth  15.  Note  that  BMC  takes 
less  than  15  mins  for  the  two  buggy  versions  because  the  counter  example  depth  is  only 
12.  For  these  buggy  versions,  BDD  based  model  checker  does  not  finish  even  after  an  hour 
(the  abstract  models  for  buggy  versions  were  not  optimized). 

Flash  protocol.  We  constructed  an  abstract  model  for  Flash  protocol  using  both  the 
optimizations  described  in  Section  3.5.  With  counter  threshold  1  (cf.  Section  3.4.2),  we 
get  a  spurious  counterexample  due  to  the  three-hop  case.  The  spurious  counter  example  is 
as  follows:  suppose  counter  eexci  corresponds  to  an  exclusive  local  state.  Suppose  now  that 
the  reference  process  requests  exclusive  access.  The  central  process  forwards  this  request 
to  the  environment  process  which  is  represented  by  the  counter  eexci.  After  serving  the 
request  the  environment  process  goes  into  an  invalid  state,  and  thus  eexci  should  become  0. 
But,  since  1  stands  for  many  in  the  abstract  model,  there  is  an  abstract  transtion  that  keeps 
eexd  as  1.  This  leads  to  the  violation  of  the  safety  property. 

To  get  rid  of  this  spurious  counterexample,  we  track  counters  corresponding  to  exclu¬ 
sive  local  states  more  carefully.  We  refine  the  abstract  model  by  increasing  the  counter 
threshold  to  2  for  those  environments  where  the  cache  is  in  the  exclusive  state.  The  result¬ 
ing  model  is  precise  enough  to  prove  the  safety  property.  The  model  checking  time  was 
about  7  hours  (25700  seconds). 

The  table  shown  in  Figure  3.1  summarizes  our  experimental  results. 

Remark  10.  For  the  protocols  that  do  not  satisfy  the  cache  coherence  property,  the  coun¬ 
terexamples  always  involve  just  two  caches.  For  example,  the  version  of  German’s 
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Protocol 

Optimizations 

MC 

Cex 

Time 

German(std) 

1 

BDD 

No 

3  hrs 

German(std) 

1,2 

BDD 

No 

5  mins 

German)  Buggy  1) 

1 

BMC 

Yes  (len=12) 

15  mins 

German) Buggy  2) 

1 

BMC 

Yes  (len=12) 

15  mins 

German(4-Chan) 

1.2 

BDD 

Yes  (len=15) 

7  mins 

Flash 

1,2 

BDD 

No 

7  hrs 

Figure  3.1:  Results  for  Cache  Coherence  Protocols 


protocol  with  four  channels  has  a  bug  involving  only  two  caches.  It  seems  to  be  the  case 
that  having  just  3  caches  might  exhaust  all  the  possibilities  for  a  cache  coherence  protocol 
but  this  is  hard  to  prove. 

All  the  experiments  were  run  on  a  1.5  GHz  machine  with  3GB  main  memory.  Since 
the  time  for  extracting  the  abstract  model  is  negligible  compared  to  the  model  checking 
time,  the  reported  times  are  runtimes  of  the  model  checker. 

3.8  Conclusion 


We  have  presented  a  natural  application  of  environment  abstraction  that  allows  us  to 
automatically  verify  complex  cache  coherence  protocols.  We  first  describe  a  high  level 
description  language  to  model  such  protocols.  Our  language  is  natural  and  facilitates  easy 
protocol  descriptions  in  the  spirit  of  Lamport’s  TLA  (although  it  is  much  more  restricted). 
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In  contrast  to  previous  approaches  [67],  we  use  symbolic  model  checkers  in  this  chapter. 

To  keep  the  computation  feasible,  we  over- approximate  the  abstract  transition  system 
one  statement  at  a  time,  similar  to  predicate  abstraction  for  software.  Moreover,  we  use  the 
results  of  Section  3.5  to  eliminate  semantically  redundant  set  variables,  and  thus  to  reduce 
the  size  of  the  abstract  models. 

In  the  next  section,  we  present  the  descriptions  of  the  protocols  that  we  verified.  In 
the  next  chapter  we  will  consider  the  application  of  environment  abstraction  to  mutual 
exclusion  protocols. 


3.9  Protocol  Descriptions 

A  simplified  version  of  the  Flash  cache  coherence  protocol  is  shown  in  our  input  lan¬ 
guage  below.  The  simplifications  are  as  follows: 

•  In  the  original  Flash  protocol,  the  directory  (i.e.  the  central  process)  distinguishes 
between  the  home  cache  and  the  other  caches.  While  our  abstraction  method  can 
handle  the  full  version,  the  current  model  checkers  cannot  handle  the  abstract  model 
that  is  generated. 

•  The  communication  between  the  central  process  (directory)  and  local  processes  (the 
caches)  is  modelled  by  having  two  variables  chanin  and  chanout  per  cache.  These 
two  variables  serve  as  incoming  and  outgoing  channels  for  each  cache.  Use  of  two 
variables  implies  that  the  communication  buffers  are  bounded,  in  fact,  are  of  size  1 . 
This  restriction  is  similar  to  the  restriction  seen  in  German’s  Protocol. 
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•  For  the  three-hop  case,  we  exploit  the  fact  that  at  any  point  in  time,  for  a  given 
cache  line,  there  can  be  only  one  three-hop  transaction.  This  fact  can  be  seen  just 
by  examining  the  code  for  the  central  process.  So  to  reduce  state  space,  instead  of 
storing  a  pointer  at  each  cache,  we  store  one  pointer  at  the  central  process  (named 
threeptr  in  the  model  below).  Since  there  is  only  one  three-hop  transaction  and  all 
the  information  on  the  caches  involved  is  known,  we  model  the  three-hop  transaction 
as  part  of  the  central  process.  This  does  not  change  the  semantics  of  the  three- 
hop  transaction  in  any  way,  it  is  just  a  convenient  representation  in  our  modelling 
language. 


The  central  process  reads  a  message  from  a  cache  via  a  transition  involving  pick  ac¬ 
tion.  For  example,  the  transition 


currcmd  =  empty  A  read  =  no:  Do  Actions 

goto  currcmd  =  get  A  read  =  yes 
pick  temptr  from  chanout  =  get 

says,  if  current  command  (CURRCMD)  is  empty,  and  nothing  has  been  read  (READ  = 
no),  then  do  the  action  pick  temptr  from  chanout  =  get.  This  action  sets  the  pointer 
temptr  to  some  cache  satisfying  the  condition  chanout  =  get,  that  is,  some  cache  which 
has  sent  a  get  message.  Then  the  current  command  is  set  to  get  and  READ  is  marked  yes. 

The  expression  sharlist  =  <f>  indicates  that  the  set  sharlist  is  empty.  Finally,  the 
statement  remote  sharlist  goto  chanin  =  inv  denotes  the  action  where  all  caches  present 
in  sharlist  get  an  invalidate  (inv)  message. 
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FLASH  Protocol 


Local  Process 

Local  Vars 

Cachestate:  inv,  shar,  excl; 
invmarked:  yes,  no; 

CHANIN:  empty,  put,  putx,  inv,  NAK; 

CHANOUT:  empty,  get,  getx,  invack; 

Local  Transitions 

cachestate  =  inv  A  chanout  =  emtpy:  goto  chanout  =  get 

cachestate  =  inv  A  chanout  =  emtpy.  goto  chanout  =  getx 

cachestate  =  shar  A  chanout  =  emtpy.  goto  chanout  =  getx 

cachestate  =  inv  A  chanin  =  inv:  goto  invmarked  =  yes 

cachestate  =  inv  A  invmarked  =  no  A  chanin  =  put:  goto  cachestate 

chanin  =  empty 


shar  A 
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cache  state  =  inv  A  invmarked  =  yes  A  chanin  =  put :  goto  invmarked  =  no  A 
chanin  =  empty 

cache  state  =  inv  A  invmarked  =  no  A  chanin  =  putx:  goto  cache  state  =  excl  A 
chanin  =  empty 

cachestate  =  inv  A  invmarked  =  yes  A  chanin  =  putx:  goto  invmarked  =  no  A 
chanin  =  empty 

cachestate  =  shar  A  chanin  =  inv:  goto  cachestate  =  inv  A  chanout  =  invack 
cachestate  =  excl  A  chanin  =  inv:  goto  cachestate  =  inv  A  chanout  =  invack 
cachestate  =  inv  A  chanin  =  NAK :  goto  chanin  =  empty 
cachestate  =  shar  A  chanin  =  NAK:  goto  chanin  =  empty 

Central  Process 

Central  vars 

dirty:  no,  yes; 
pending:  no,  yes; 
hdptr:  ptr; 

HD  valid:  no,  yes; 

CURRCMD:  empty,  get,  getx,  invack; 

THREEHOP:  empty,  get,  getl,  getx,  getxl; 
threehoptr:  ptr; 

CHECKSHRLIST:  no,  yes; 
sharlist:  set; 
temptr:  ptr; 
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Central  Transitions 

currcmd  =  empty  A  read  =  no:  Do  Actions 

goto  currcmd  =  get  A  read  =  yes 
pick  temptr  from  chanout  =  get 
currcmd  =  empty  A  read  =  no:  Do  Actions 

goto  currcmd  =  getx  A  read  =  yes 
pick  temptr  from  chanout  =  getx 
currcmd  =  empty  A  read  =  no:  Do  Actions 

goto  currcmd  =  invack  A  read  =  yes 
pick  temptr  from  chanout  =  invack 
currcmd  =  empty  A  read  =  yes:  Do  Actions 
goto  read  =  no 

remote  temptr  goto  chanout  =  empty 
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currcmd  =  getAread  =  no  Amending  =  no  A  dirty  =  no  A  chanout[temptr]  =  empty. 

Do  Actions 

goto  currcmd  =  empty 
remote  temptr  goto  chanin  =  put 

currcmd  =  getAread  =  no  Apending  =  noAdirty  =  yes  Achanout[temptr\  =  empty : 

Do  Actions 

goto  currcmd  =  empty  A  threehop  =  get  A  pending  =  yes 
assign  threehoptr  =  temptr 
threehop  =  get  A  cache state[hdptr]  =  excl :  Do  Actions 
goto  threehop  =  getl 
remote  hdptr  goto  cachestate  =  inv 

currcmd  =  getAread  =  no  Apending  =  yes  A  chanout  [temptr]  =  empty.  Do  Actions 
goto  currcmd  =  empty 
remote  temptr  goto  chanin  =  NAK 

currcmd  =  getx  A  read  =  no  A  pending  =  yes  A  chanout[temptr]  =  empty.  Do 

Actions 

goto  currcmd  =  empty 

remote  temptr  goto  chanin  =  NAK 
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currcmd  =  getx  A  read  =  no  A  pending  =  no  A  dirty  =  no  A  hdvalid  =  no  A 
chanout[temptr]  =  empty:  Do  Actions 
goto  currcmd  =  empty 
remote  temptr  goto  chanin  =  putx 

currcmd  =  getx  A  read  =  no  A  pending  =  no  A  dirty  =  yes  A  chanout[temptr\  = 
empty :  Do  Actions 

goto  currcmd  =  empty  A  threehop  =  getx  A  pending  =  yes 
assign  threehoptr  =  temptr 

currcmd  =  getx  A  read  =  no  A  pending  =  no  A  dirty  =  no  A  hdvalid  =  yes  A 
chanout[temptr]  =  empty:  Do  Actions 

goto  currcmd  =  empty  A  pending  =  yes 
remote  sharlist  goto  chanin  =  inv 
remote  temptr  goto  chanin  =  putx 
threehop  =  getx  A  cache state[hdptr\  =  excl:  Do  Actions 
goto  threehop  =  getxl 
remote  hdptr  goto  cachestate  =  inv 
currcmd  =  invack  A  read  =  no:  Do  Actions 

goto  currcmd  =  empty  A  checksharlist  =  yes 
check  sharlist  =  yes  A  sharlist  =  $:  Do  Actions 

goto  chechsharlist  =  no  A  pending  =  no 
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Standard  German’s  Protocol 


Local  Process 

Local  Vars 

Cachestate:  {invalid,  shar,  excl} 
chanl:  {Empty,  reqshar,  reqexcl} 
chan2:  {Empty,  invalid,  grantshar,  grantexcl} 
chan3:  {Empty,  Invack} 

Local  Transitions 

cachestate  =  invalid  A  chanl  =  empty,  goto  chanl  =  reqshar ; 
cachestate  =  invalid  A  chanl  =  empty,  goto  chanl  =  reqexcl ; 
cachestate  =  shar  A  chanl  =  empty:  goto  chanl  =  reqexcl ; 
chanl  =  invalid  A  chanS  =  empty:  goto  chanl  =  empty  A  chan3 
cachestate  =  invalid ; 

chanl  =  grantshar:  goto  chan2  =  empty  A  cachestate  =  shar ; 
chan2  =  grantexcl:  goto  chan2  =  empty  A  cachestate  =  excl ; 


invack  A 
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Central  Process 


Central  Vars 

exclgrant:  {yes,  no} 

currcmd:  {empty,  reqshar,  reqexcl} 

currclient:  ptr 

sharlist:  set 

Invlist:  set 

read:  {yes,  no} 

tmpreadl:  {no,  yes} 

temptr2:  ptr 

tmpread2:  {no,  yes} 

temptrl:  ptr 

Central  Transitions 

currcmd  =  empty  A  read  =  no:  Do  Actions 
goto  read  =  yes 

pick  currclient  from  { local  chanl[local]=reqshar  V 
chan  1  [  local ] = reqexcl } 

currcmd  =  empty  A  read  =  yes  A  chanl[currclient]  =  reqshar:  Do  Actions 
goto  read  =  no  A  currcmd  =  reqshar 
remote  currclient  goto  chanl  =  Empty 
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currcmd  =  empty  A  read  =  yes  A  chanl[curr client]  =  reqexcl :  Do  Actions 
goto  read  =  no  A  currcmd  =  reqexcl 
remote  currclient  goto  chanl  =  Empty 


assign  Invlist  =  sharlist 

currcmd  =  reqshar  A  grantexcl  =  no  A  chan2[curr  client]  =  empty.  Do  Actions 
goto  currcmd  =  empty 
remote  currclient  goto  chan 2  =  grantshar 
Add  currclient  to  sharlist 

currcmd  =  reqexcl  A  sharlist  =  $  A  chan2[curr client]  =  empty.  Do  Actions 
goto  currcmd  =  empty  A  grantexcl  =  yes 
remote  currclient  goto  chan2  =  grantexcl 
Add  currclient  to  sharlist 

currcmd  =  reqshar  A  tmpreadl  =  no  A  grantexcl  =  yes:  Do  Actions 
goto  tmpreadl  =  yes 

pick  temptr  1  from  {local\(local  €  Invlist )  A  chan2[local]  =  Empty} 
currcmd  =  reqexcl  A  tmpreadl  =  no:  Do  Actions 
goto  tmpreadl  =  yes 

pick  temptr  1  from  {local\(local  €  Invlist )  A  chan2[local]  =  Empty} 
currcmd  =  reqshar  A  tmpreadl  =  yes:  Do  Actions 
goto  tmpread  =  no 
remote  temptr  1  goto  chan2  =  invalid 
Remove  temptr  1  from  Invlist 
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currcmd  =  reqexcl  A  tmpreadl  =  no:  Do  Actions 


goto  tmpreadl  =  yes 

remote  temptr  1  goto  chan2  =  invalid 

Remove  temptr  1  from  Invlist 

currcmd  =  reqshar  A  tmpread2  =  no  A  grantexcl  =  yes :  Do  Actions 
goto  tmpread2  =  yes 

pick  temptr 2  from  {local\chan3[local\  =  invack} 
currcmd  =  reqexcl  A  tmpread2  =  no:  Do  Actions 
goto  tmpreadl  =  yes 

pick  temptr 2  from  {local\chan3[local\  =  invack} 
currcmd  =  reqshar  A  tmpread2  =  yes:  Do  Actions 

goto  tmpread2  =  no  A  grantexcl  =  no 
remote  temptr2  goto  chan3  =  Empty 
currcmd  =  reqexcl  A  tmpread2  =  yes:  Do  Actions 

goto  tmpread2  =  no  A  grantexcl  =  no 
remote  temptr2  goto  chan2  =  invalid 
Remove  temptr2  from  sharlist 
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Buggy  versions  of  German’s  Protocol 


As  a  sanity  check,  we  created  two  buggy  versions  of  German’s  protocol  to  see  if  our 
method  is  able  to  catch  the  bugs.  The  buggy  versions  are  described  below. 

Buggy  version  1.  In  the  first  buggy  version,  after  the  directory  grants  exclusive  access  to  a 
cache,  it  fails  to  set  the  grantexcl  variable  to  true.  That  is,  instead  of  the  correct  transition 

currcmd  =  reqexcl  A  sharlist  —  <b  A  chan2[curr  client]  =  empty.  Do  Actions 
goto  currcmd  =  empty  A  grantexcl  =  yes 
remote  currclient  goto  chan2  =  grantexcl 
Add  currclient  to  sharlist 

we  have  the  faulty  version 

currcmd  =  reqexcl  A  sharlist  =  <f>  A  chan2[curr  client]  =  empty.  Do  Actions 
goto  currcmd  =  empty 
remote  currclient  goto  chan2  =  grantexcl 
Add  currclient  to  sharlist 
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Buggy  version  2.  For  the  second  buggy  version,  the  directory  grants  a  shared  request  even 
if  grantexcl  variable  is  true  (that  is,  some  cache  has  been  granted  exclusive  access).  Thus, 
instead  of  the  normal  transition 


currcmd  =  reqshar  A  grantexcl  =  no  A  chan2[curr  client]  =  empty.  Do  Actions 
goto  currcmd  =  empty 
remote  currclient  goto  chan2  =  grantshar 
Add  currclient  to  sharlist 


we  have 

currcmd  =  reqshar  A  grantexcl  =  yes  A  chan2[curr client]  =  empty.  Do  Actions 
goto  currcmd  =  empty 
remote  currclient  goto  chan2  =  grantshar 
Add  currclient  to  sharlist 
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German’s  Protocol  with  Extra  channels  (4-chan) 


Local  Process 

Local  Vars 

Cachestate:  {invalid,  shar,  excl} 
chanl:  {Empty,  reqshar,  reqexcl} 
chan2:  {Empty,  grantshar,  grantexcl} 
chan3:  {Empty,  Invack} 
chan4:  {Empty,  invalid  } 

Local  Transitions 

cachestate  =  invalid  A  chanl  =  empty,  goto  chanl  =  reqshar ; 
cachestate  =  invalid  A  chanl  =  empty,  goto  chanl  =  reqexcl ; 
cachestate  =  shar  A  chanl  =  empty,  goto  chanl  =  reqexcl ; 
chanA  =  invalid  A  chan3  =  empty,  goto  chan2  =  empty  A  charhl 
cachestate  =  invalid 

chan2  =  grantshar:  goto  chan2  =  empty  A  cachestate  =  shar 
chan2  =  grantexcl:  goto  chan2  =  empty  A  cachestate  =  exc/ 


invack  A 
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Central  Process 


Central  Vars 

exclgrant:  {yes,  no} 

currcmd:  {empty,  reqshar,  reqexcl} 

currclient:  ptr 

sharlist:  set 

Invlist:  set 

read:  {yes,  no} 

tmpreadl:  {no,  yes} 

temptr2:  ptr 

tmpread2:  {no,  yes} 

temptrl:  ptr 

Central  Transitions 

currcmd  =  empty  A  read  =  no:  Do  Actions 
goto  read  =  yes 

pick  currclient  from  {local\  chanl[local]=reqshar  V 
chan  1  [  local] = reqexcl } 
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currcmd  =  empty  A  read  =  yes  A  chanl[curr client]  =  reqshar:  Do  Actions 
goto  read  =  no  A  currcmd  =  reqshar 
remote  currclient  goto  chanl  =  Empty 

currcmd  =  empty  A  read  =  yes  A  chanl[curr  client]  =  reqexcl:  Do  Actions 
goto  read  =  no  A  currcmd  =  reqexcl 
remote  currclient  goto  chanl  =  Empty 
Assign  Invlist  =  sharlist 

currcmd  =  reqshar  A  grantexcl  =  no  A  chan2[curr client]  =  empty :  Do  Actions 
goto  currcmd  =  empty 
remote  currclient  goto  chan2  =  grantshar 
Add  currclient  to  sharlist 

currcmd  =  reqexcl  A  sharlist  =  $  A  chan2[curr client]  =  empty:  Do  Actions 
goto  currcmd  =  empty  A  grantexcl  =  yes 
remote  currclient  goto  chan2  =  grantexcl 
Add  currclient  to  sharlist 

currcmd  =  reqshar  A  tmpreadl  =  no  A  grantexcl  =  yes:  Do  Actions 
goto  tmpreadl  =  yes 

pick  temptrl  from  {local\Invlist[local]  =  in  A  chan2[local] 

Empty} 

currcmd  =  reqexcl  A  tmpreadl  =  no:  Do  Actions 
goto  tmpreadl  =  yes 

pick  temptrl  from  {local\Invlist[local]  =  in  A  chan2[local] 

Empty } 
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currcmd  =  reqshar  A  tmpreadl  =  yes:  Do  Actions 
goto  tmpread  =  no 


remote  temptr  1  goto  chanA  =  invalid 
Remove  temptr  1  from  Invlist 
currcmd  =  reqexcl  A  tmpreadl  =  no:  Do  Actions 
goto  tmpreadl  =  yes 
remote  temptr  l  goto  chan2  =  invalid 
Remove  temptrl  from  Invlist 

currcmd  =  reqshar  A  tmpread2  =  no  A  grantexcl  =  yes:  Do  Actions 
goto  tmpread2  =  yes 

pick  temptr 2  from  { local \ chan3[local\  =  invack} 
currcmd  =  reqexcl  A  tmpread2  =  no:  Do  Actions 
goto  tmpreadl  =  yes 

pick  temptr 2  from  {local\chan3[local\  =  invack} 
currcmd  =  reqshar  A  tmpread2  =  yes:  Do  Actions 

goto  tmpread2  =  no  A  grantexcl  =  no 
remote  temptr2  goto  chan3  =  Empty 
currcmd  =  reqexcl  A  tmpread2  =  yes:  Do  Actions 

goto  tmpread2  =  no  A  grantexcl  =  no 
remote  temptr 2  goto  chan2  =  invalid 
Remove  temptr2  from  sharlist 


113 


114 


Chapter  4 


Environment  Abstraction  for 
Verification  of  Mutex  Protocols 


4.1  Introduction 


Given  a  set  of  contending  processes,  providing  them  mutually  exclusive  access  to  re¬ 
sources  is  among  the  most  basic  primitives  that  any  computer  system  requires.  As  such, 
mutual  exclusion  protocols  have  received  considerable  attention  in  the  distributed  comput¬ 
ing  literature.  These  protocols  are  usually  designed  to  be  correct  no  matter  what  the  exact 
number  of  processes  running  them.  Thus,  mutual  exclusion  protocols  are  classic  examples 
of  parameterized  systems.  Note  that,  in  contrast  to  cache  coherence  protocols,  in  mutual 
exclusion  protocols  each  individual  process  itself  might  have  infinite  state  space  as  they 
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can  have  unbounded  data  variables  in  addition  to  finite  control  variables. 

Several  model  checking  based  methods,  including  Indexed  Predicates  [52],  Invisible 
Invariants  [64],  and  counter  abstraction  [66],  have  been  proposed  to  parameterically  verify 
mutual  exclusion  protocols.  The  Indexed  Predicates  method  [52;  53],  as  already  men¬ 
tioned,  is  a  new  form  of  predicate  abstraction  for  infinite  state  systems.  This  method 
works  only  for  safety  properties  and  not  for  liveness  properties. 

The  idea  behind  Invisible  Invariants  technique,  introduced  in  a  series  of  papers  [3; 
41;  42;  64],  is  to  find  an  invariant  for  the  parameterized  system  by  examining  concrete 
systems  for  low  valuations  of  the  parameter(s).  In  [3],  a  modified  version  of  the  Bakery 
algorithm  is  verified  -  the  original  Bakery  algorithm  is  modified  to  eliminate  unbounded 
data  variables. 

Pnueli  et  al.  [66],  who  coined  the  term  counter  abstraction ,  show  how  systems  com¬ 
posed  of  symmetric  and  finite  state  processes  can  be  handled  automatically.  However, 
protocols  that  either  break  symmetry  by  exploiting  knowledge  of  process  ids  or  that  have 
infinite  state  spaces  require  manual  intervention.  Thus,  the  verification  of  Szymanski’s  and 
the  Bakery  protocol  in  [66]  requires  manual  introduction  of  new  variables.  All  the  three 
methods  mentioned  above  make  use  of  the  atomicity  assumption. 

In  this  chapter,  we  will  show  how  environment  abstraction  can  be  used  to  verify  mutual 
exclusion  protocols  automatically  under  the  atomicity  assumption.  Environment  abstrac¬ 
tion  essentially  addresses  the  two  disadvantages  of  counter  abstraction  by  generalizing  the 
idea  of  counting:  since  the  state  space  is  infinite,  we  do  not  count  the  processes  in  a  given 
state  as  in  traditional  counter  abstraction,  but  instead  we  count  the  number  of  processes 
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Figure  4.1:  Abstraction  Mapping. 


satisfying  a  given  predicate. 

Figure  4.1  visualizes  the  intuition  underlying  environment  abstraction.  The  grey  box 
on  the  left  hand  side  represents  a  concrete  state  of  a  system  with  16  concurrent  processes. 
The  different  colors  of  the  disks/processes  represent  the  internal  states  of  the  processes, 
i.e.,  the  state  of  the  control  variables. 

The  star-shaped  graph  on  the  right  hand  side  of  Figure  4.1  represents  an  abstract  state. 
The  abstract  state  contains  one  distinguished  process,  the  reference  process  x,  which  is  at 
the  center  of  the  star.  In  this  example,  the  reference  process  x  represents  process  1  of  the 
concrete  state.  The  disks  on  the  circumference  of  the  star  represent  the  environment  of  the 
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reference  process.  Intuitively,  the  goal  of  the  abstraction  is  to  embed  the  reference  process 
x  of  the  abstract  state  into  an  abstract  environment  as  rich  as  the  environment  that  process 
1  has  in  the  concrete  state.  Thus,  the  abstract  state  represents  the  concrete  state  “from  the 
point  of  view  of  process  1.” 

To  describe  the  environment  of  a  process,  we  need  to  consider  the  relationships  which 
can  hold  between  the  data  variables  of  two  processes.  We  can  graphically  indicate  a  spe¬ 
cific  relationship  between  any  two  processes  by  a  corresponding  arrow  between  the  pro¬ 
cesses;  the  form  of  the  arrow  (full,  dashed,  etc.)  determines  which  relationship  the  two 
processes  have.  In  Figure  4.1,  we  assume  that  we  have  only  two  relationships  R\  and  R2. 
For  example,  R\  (x,  y )  might  say  that  the  local  variable  t  of  process  x  has  the  same  value 
as  local  variable  t  in  process  y,  while  R2(x,  y)  might  say  that  t  has  different  values  in 
processes  x  and  y.  Relationship  Il\  is  indicated  by  a  full  arrow,  and  R2  is  indicated  by 
a  dashed  arrow.  For  better  readability,  not  all  relationships  between  the  16  processes  are 
drawn. 

Note  that  a  single  abstract  state  generally  represents  an  infinite  number  of  concrete 
states.  Moreover,  a  given  concrete  state  gives  rise  to  several  abstract  states,  each  of  which 
is  induced  by  choosing  a  different  possible  reference  process.  For  example,  the  concrete 
state  in  Figure  4.1  may  induce  up  to  16  abstract  states,  one  for  each  process. 

Using  the  abstraction  method  described  here,  we  have  been  able  to  verify  automati¬ 
cally  the  safety  and  liveness  properties  of  two  well  known  mutual  exclusion  algorithms, 
namely  Lamport’s  Bakery  algorithm  [54]  and  Szymanski’s  algorithm  [77].  While  safety 
and  liveness  properties  of  Szymanski’s  algorithm  have  been  automatically  verified  with 
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atomicity  assumption  by  Baukus  et  al.  [6],  this  is  the  first  time  both  safety  and  liveness 
of  Lamport’s  Bakery  algorithm  have  been  verified  (with  the  atomicity  assumption)  at  this 
level  of  automation. 


4.2  System  Model  for  Mutual  Exclusion  Protocols 

As  in  Section  2.2,  we  consider  parameterized  system  V{K),  K  >  1,  composed  of  (pa¬ 
rameter)  K  processes.  Unlike  the  system  model  for  cache  coherence  protocols,  there  is  no 
central  process  in  the  systems  considered  in  this  chapter.  Technically,  V(K)  is  a  Kripke 
structure  (SK,  IK,  L K .  RK ).  The  set  of  global  states  SK  and  the  global  transition  relation 
Rk  are  formed  by  composing  the  individual  states  and  the  transition  relations  of  the  K 
processes.  Since  mutual  exclusion  protocols  are  asynchronous  system,  the  global  transi¬ 
tion  relation  RK  is  the  asynchronous  composition  of  the  individual  the  transition  relations. 
In  the  following  we  will  describe  the  state  spaces  and  transition  relations  of  the  individual 
processes. 

4.2.1  Local  State  Variables 

Each  process  has  two  sets  of  variables:  the  control  variables  and  the  data  variables.  In¬ 
tuitively,  the  two  sets  of  variables  serve  different  purposes.  The  control  variables  de¬ 
termine  the  internal  control  state  of  the  process.  Without  loss  of  generality,  we  can  as¬ 
sume  that  there  is  only  one  control  variable  pc  per  process.  The  set  of  data  variables, 
U  =  {ui, . . .  Ud},  contain  actual  data  which  can  be  read  by  other  processes  to  calculate 
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their  own  data  variables.  We  could  also  assume  that  there  is  only  one  data  variable  per 
process,  but  computation  of  the  abstract  model  in  presence  of  multiple  data  variables  is 
different  from  the  single  data  variable  case.  Hence,  we  consider  the  full  general  model. 

We  will  usually  refer  to  processes  and  their  variables  via  their  process  ids.  In  particular, 
pc[i]  and  Uk[i\  denote  the  variables  pc  and  of  the  process  with  id  i.  A  process  can  use 
the  reserved  expression  slf  to  refer  to  its  own  process  id.  When  a  protocol  text  contains 
the  variables  pc  or  Uk  without  explicit  reference  to  a  process  id,  then  this  stands  for  pc  [slf] 
and  it/,. [slf  respectively.  Note  that  all  processes  in  a  system  ViK)  are  identical  except  for 
their  ids.  Thus,  the  process  ids  are  the  only  means  to  break  the  symmetry  between  the 
processes. 

A  formula  of  the  form  pc  =  const  is  called  a  control  assignment.  The  range  of  pc  is 
called  the  set  of  control  locations. 

Though  we  assume  that  there  is  only  one  control  variable,  in  program  texts  we  may 
take  the  freedom  to  use  more  than  one  finite  range  control  variable  as  it  makes  the  program 
better  readable. 


4.2.2  Transition  Constructs 

We  will  describe  the  transition  relation  of  the  processes  in  terms  of  two  basic  constructs, 
guarded  transitions  for  the  finite  control,  and  the  more  complicated  update  transitions  for 
modifying  the  data  variables.  A  guarded  transition  has  the  form 


120 


pc  =  Li  :  if  Votr  7^  slf. (/(slf.  otr)  then  goto  pc  =  L2  else  goto  pc  =  L3 


or  shorter 

Li  :  if  Votr  7^  slf. (/(slf.  otr)  then  goto  L2  else  goto  L3 

where  L1;  L2,  L3  are  control  locations.  In  the  guard  Votr  7^  slf. (/(slf.  otr)  the  variable  otr 
ranges  over  the  process  ids  of  all  other  processes.  The  condition  (/(slf,  otr)  can  be  any 
formula  involving  the  data  variables  of  processes  slf,  otr  and  the  pc  variable  of  otr.  The 
semantics  of  a  guarded  transition  is  straightforward:  in  control  location  L1?  the  process 
evaluates  the  guard  and  changes  to  control  location  L2  or  L:>  accordingly. 

Update  transitions  are  needed  to  describe  protocols  such  as  the  Bakery  algorithm  where 
a  process  computes  a  data  value  depending  on  all  values  that  it  can  read  from  other  pro¬ 
cesses.  For  example,  the  Bakery  algorithm  has  to  compute  the  maximum  of  a  certain  data 
variable  (the  “ticket  variable”)  in  all  other  processes.  Thus,  we  define  an  update  transition 
to  have  the  general  form 


Li  :  for  all  otr  7^  slf  if  T (slf,  otr)  then  Uk  :=  <l>(otr) 

goto  L2 

where  L\  and  L2  are  control  assignments,  and  T(slf.otr)  is  a  condition  involving  data 
variables  of  processes  slf,  otr.  The  semantics  of  the  update  transition  is  best  understood 
in  an  operational  manner:  in  control  location  L\,  the  process  scans  over  all  the  other 
processes  (in  a  nondeterministically  chosen  order),  and  for  each  process  otr,  checks  if  the 
formula  T (slf,  otr)  is  true.  In  this  case,  the  process  changes  the  value  of  its  data  variable 
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Uk  according  to  »  /,  :=  <X>  (otr) ,  where  <I>  (  otr  )  is  an  expression  involving  variables  of  process 
otr.  Thus,  the  variable  Uk  can  be  reassigned  multiple  times  within  a  transition.  Finally, 
the  process  changes  to  control  location  L2.  We  assume  that  both  guarded  and  update 
transitions  are  atomic,  i.  e. ,  during  their  execution  no  other  process  makes  a  move. 

Example  4.2.1.  As  an  example  of  a  protocol  written  in  this  language,  consider  a  pa¬ 
rameterized  system  'P(N)  where  each  process  P  has  one  finite  variable  pc  :  {1,2,3} 
representing  a  program  counter,  one  unbounded/integer  variable  t  :  Int,  and  executes  the 
following  program: 

1  :  goto  2 

2  :  if  Votr  ^  slf.f [slf]  ^  t [otr]  then  goto  3 

3  :  t  :=  t [otr]  +  1;  goto  1 

The  statement  1  :  goto  2  is  syntactic  sugar  for 

pc  =  1  :  if  Votr  ^  slf.true  then  goto  pc  =  2  else  goto  pc  =  1 

Similarly,  3  :  t  :=  t [otr]  +  1;  goto  =  1  is  syntactic  sugar  for 

pc  =  3  :  if  Votr  ^  slf.true  then  t  :=  f  [otr]  +  1  goto  pc  =  1. 

This  example  illustrates  that  most  commonly  occurring  transition  statements  in  protocols 
can  be  written  in  our  input  language.  □ 

Note  that  we  have  not  specified  the  operations  and  predicates  that  are  used  in  the  con¬ 
ditions  and  assignments.  Essentially,  this  choice  depends  on  the  protocols  and  the  power 
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of  the  decision  procedures  used.  For  the  protocols  considered  in  this  paper,  we  need  lin¬ 
ear  order  and  equality  on  data  variables  as  well  as  incrementation,  i.e.,  addition  by  one. 
The  last  section  of  this  chapter  contains  Szymanski’s  protocol  and  the  Bakery  protocol 
described  in  our  input  language. 

4.3  Environment  Abstraction  for  Mutual  Exclusion  Pro¬ 
tocols 

In  this  section,  we  show  how  to  apply  environment  abstraction  for  mutual  exclusion  pro¬ 
tocols.  In  Section  4.5,  we  will  discuss  how  to  actually  compute  abstract  models. 

To  apply  environment  abstraction,  we  have  to  give  the  abstract  descriptions  and  the 
abstraction  mapping  from  the  concrete  states  to  the  abstract  states.  We  also  have  to  prove 
that  the  abstract  descriptions  satisfy  the  coverage  and  congruence  properties  with  respect 
to  the  set  of  labels  we  use.  We  consider  these  issues  below. 

4.3.1  Specifications  and  Labels 

The  typical  properties  that  we  are  interested  in  verifying  can  be  expressed  as  shown  below. 

•  A  single  process  liveness  property  can  be  written  as 

Va;.AG(pc[a:]  =  try  =>  F(pc[x]  =  crit)) 

“For  all  processes  x,  the  following  holds:  If  process  x  is  trying  to  enter  the  critical 
section  then  it  eventually  will.” 
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Va;.AG(pc[a:]  =  crit  =>■  (crit  env(x))) 


“ For  all  processes  x  the  following  invariant  holds:  If  process  x  is  in  the  critical 
section,  then  no  other  process  is  in  the  critial  section  ” 

Consequently,  the  set  of  labels  L  again  has  two  types  of  labels: 

•  pc[x]  =  L,  and 

•  L  e  env(x). 

4.3.2  Abstract  Descriptions 

Technically,  our  descriptions  reuse  the  predicates  which  occur  in  the  control  statements  of 
the  protocol  description.  Let  ,5V.  be  the  number  of  control  locations  in  the  program  P.  The 
internal  state  of  a  process  x  can  be  described  by  a  predicate  of  the  form 

pc[x]  =  L 

where  L  e  {l-./Sz,}  is  a  control  location. 

In  order  to  describe  the  relations  between  the  data  variables  of  different  processes  we 
collect  all  predicates  £V\  (x,  y), ... ,  E'P  f  x,  y )  which  occur  in  the  guards  of  the  program. 
From  now  on  we  will  refer  to  these  predicates  as  the  inter-predicates  of  the  program. 
Since  in  most  practical  protocols,  synchronization  between  processes  involves  only  one  or 
two  data  variables,  the  number  of  inter-predicates  is  usually  quite  small.  The  relationship 
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between  a  process  x  and  a  process  y  is  now  described  by  a  formula  of  the  form 

Ri{x,y )  =  ±£Vi(x,  y)  A  ...  A  ±£Pr(x,  y) 

where  ±£Vi  stands  for  £V,  or  its  negation  It  is  easy  to  see  that  there  are  2r  possible 

relationships  Ri(x,y), . . . ,  .R2r(x,  I/)  between  a:  and  y.  In  the  example  of  Figure  4.1,  the 
two  relationship  predicates  and  f?2  are  visualized  by  full  and  dashed  arrows. 

Fact  3.  The  relationship  conditions  R\  {x,  y) , . . . ,  f?2 r  (#,  y)  are  mutually  exclusive. 

Before  we  explain  the  descriptions  A  (re)  in  detail,  let  us  first  describe  the  most  im¬ 
portant  building  blocks  for  the  descriptions,  which  we  call  environment  predicates.  An 
environment  predicate  expresses  that  for  process  x  we  can  find  another  process  y  which 
has  a  given  relationship  to  process  x  and  a  certain  internal  state.  The  environment  predi¬ 
cates  thus  have  the  form 


3 y-y  f  x  A  Ri(x,  y)  A  pc[y]  =  j. 

An  environment  predicate  says  the  following:  there  exists  a  process  y  different  from  x 
whose  relationship  to  x  is  described  by  the  £V  predicates  in  R,  and  whose  internal 
state  is  j.  There  are  T  :=  2r  x  ,57.  different  environment  predicates;  we  name  them 
£i(x), . . .  ,  £t(x),  and  their  quantifier- free  matrices  Ei(x,  y), . . . ,  ET(x,  y).  Note  that  each 
Ek(x,  y)  has  the  form  y  x  A  R(x ,  y)  A  pc[y]  =  L. 

Fact  4.  If  an  environment  process  y  satisfies  an  environment  condition  Efx,  y),  then  it 
cannot  simultaneously  satisfy  any  other  environment  condition  Ej(x,  y),  i  f  j. 
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Proof.  Each  environment  condition  Ek(x,  y )  has  the  form  y  f  x  A  R(x,  y)  A  pc [y\  =  L. 
Thus  let 

Ei(x,  y)  =y  f  x  A  Rfx,  y)  A  p  c[y]  =  U 

and 

Ej(x,y)  =  V  ^xARj(x,y)  A  p c[y]  =  Lj 

Since  E,(x.  y)  and  E:j(x.  y)  are  different,  either  Rfx ,  y)  is  different  from  lifx,  y)  or 

Li  f  Lj. 

In  the  former  case,  by  Fact  3,  Rfx,  y)  and  Pifx,  y)  are  mutually  exclusive.  Thus,  if 
process  y  satisfies  Efx,  y)  then  it  cannot  satisfy  Ej(x ,  y). 

In  the  latter  case,  if  process  y  satisfies  Efx,  y)  then  the  control  location  of  process  y 
is  Li.  Since  L*  f  Lj ,  process  y  cannot  satisfy  Ej (x,  y). 

Hence,  in  both  the  cases  we  have  shown  that  if  process  y  satisfies  environment  condi¬ 
tion  Efx,  y)  then  it  cannot  satisfy  any  other  environment  condition  Efx.  y). 

□ 

Fact  5.  Given  a  state  s  and  two  different  processes  c  and  d,  there  exists  a  unique  environ¬ 
ment  condition  Ef  x.  y)  such  that  s  |=  E,  (c,  d ). 

Proof.  Let  L  be  the  control  location  of  process  d  in  state  s.  Thus,  s  f=  pc[d]  =  L  holds. 

Given  processes  c  and  d,  for  each  inter-predicate  £Vk{x,  y)  we  have  either  s  |=  £Vfc,  d) 
or  s  £Vk{c,  d).  Consider  the  formula 

F(x,y)  =  y^xApc[y}  =  LA  /\  £Vk{x,y)  A  /\  -> £Vk(x,y ). 

s\=SVk(c,d)  sY=£Vh{c,d) 
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Clearly,  s  |=  F(c,d )  by  construction.  Syntactically,  F(x,y )  is  identical  to  a  unique 
environment  condition.  By  Fact  4,  processes  c,  d  can  satisfy  at  most  one  environment 
condition.  □ 

Fact  6.  Let  Efx,  y )  be  an  environment  condition  and  Q(x,  y )  be  a  boolean  formula  over 
the  inter-predicates  £V  \  (x,  y), . . . ,  £Vr(x,  y)  and  predicates  of  the  form  pc [y]  =  L.  Then 
either  Efx,  y)  Q(x,  y)  or  Efx,  y)  =>■  ~^Q{x,  y). 

Proof.  Since  Efx^y)  has  the  form  pc [y]  =  j  A  Rk(x,y)  where  Rk(x,y )  is  a  min-term 
over  the  inter-predicates  £V\(x,  y), . . . ,  £Vr{x:  y),  E,(x.  y)  enforces  a  unique  truth  value 
for  all  atomic  subformulas  of  Q(x,  y).  □ 

We  are  ready  to  return  to  the  descriptions  A(x).  A  description  A(x)  has  the  format 

p c[x\  —  i  A  ±£i(x)  A  ±£2(x)  A  •  •  •  A  ±£T(x),  where  i  G  [1.. S]. 

Intuitively,  a  description  A  (a;)  gives  detailed  information  on  the  internal  state  of  process 
x,  and  how  the  other  processes  are  related  to  process  x.  Note  the  correspondence  of  A  (A) 
to  the  abstract  state  in  Figure  4.1:  the  control  location  i  determines  the  color  of  the  central 
circle,  and  the  £3  determine  the  processes  surrounding  the  central  one. 

Definition  4.3.1  (Abstraction  Mapping).  Let  P(K),  K  >  1,  be  a  concrete  system  and 
p  G  [1.  .K]  be  a  process.  The  abstraction  mapping  ap  induced  by  p  maps  a  global  state  s 
of  V(K)  to  an  abstract  state  (pc,  ei, . . . ,  eT)  where  pc  =  the  value  of  p c[p\  in  state  s  and 
for  all  Cj  we  have  e3  —  1  <=>  s  |=  £:I  (p) . 

We  will  now  prove  the  coverage  and  congruence  conditions  that  let  us  apply  environ¬ 
ment  abstraction. 
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Lemma  4.3.2.  Consider  a  description  A(x)  and  a  label  l(x).  Then  either  A(x)  =>  l(x ) 
or  A(x)  =>  -il(x) 

Proof.  Consider  first  the  case  where  l{x)  =  pc[:c]  =  L.  Since  A(x)  is  of  the  form 

pc[x]  —  L  A  ±£i(x)  A  ±£2(^)  A  •  •  •  A  ±£t(x) 

it  is  easy  to  see  that,  in  this  case,  A(x)  either  A(x)  =>  l(x)  or  A(x)  =>  ->l(x). 

Consider  the  second  case  where  label  l(x)  =  L  e  env(x).  Recall  that  L  e  env(x)  is 
syntactic  sugar  for  3 y.y  f  x.p c[y\  =  L.  The  description  A(x)  is  of  the  form 

pc[x]  =  L  A  ±£\{x)  A  ±£2(x)  A  •  •  •  A  ±£t(x) 

where  each  £,{x)  is  of  the  form 

3 y.y  f  X  A  Rj(x,  y)  A  pc [y]  =  Lt 

Consider  all  those  environment  conditions  £t(x)  of  the  form 

3 y.y  f  X  A  Rj(x,  y)  A  pc[y)  =  L 

That  is,  those  environment  conditions  that  require  the  other  process  y  to  be  in  control 
location  L.  Denote  this  set  of  environment  conditions  by  £/,. 

Now 

A(x)  =>  \J  ±£i(x)  (*) 

£i{x)e£L 

where  the  polarity  of  each  £fx)  in  the  consequent  is  exactly  as  in  the  description  A(x'). 
Suppose  at  least  one  environment  condition,  say  £j(x),  in  £L  appears  un-negated  in  the 
consequent  of  (*).  Then, 

A  (a;)  =>  £j(x)  (f) 
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Since  £j(x)  is  of  the  form 


3 y.y  ±  X  A  Rk(x,  y)  A  pc [y]  =  L 

it  follows  that 

£j(x)  =>  3 y.y  ±  x  A  p c[y]  =  L. 

Thus,  we  have 

A(x)  =>  3 y.y  ±  x  A  p c[y]  =  L 

in  case  at  least  one  of  the  environment  conditions  in  El  appears  un-negated  in  A  (a;). 

For  the  other  case,  suppose  none  of  the  environment  conditions  in  El  appear  unnegated 
in  A(x).  Then  we  have 

A(x)  =>  /\  ->£i(x) 

Si(x)££L 

or  equivalently, 

A(V)  =>►  -.(  \J  Et(x)) 

£i(x)e£L 

Now  Ei(x)  is  of  the  form 

3 y.y  i-  X  A  Rk(x,  y)  A  p c[y]  =  L 
and  where  each  Rk(x,  y)  is  of  the  form 

Rk{x,  y)  A  ±£V1(x,  y)  A  ...  A  ±£Vr(x,  y) 

Since  the  set  of  relation  predicates  Rk(x,  y)  is  formed  by  taking  all  possible  cubes  over  the 
inter-predicates  £V\{x ,  y), . . . ,  £VT(x ,  y)  it  follows  that 

V  Rk(x,y)  =  true 
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This  means  at  least  one  of  the  relation  predicates  must  be  true.  Assume  without  loss  of 
generality  that  Rp(x,y )  is  true.  Let  the  corresponding  environment  condition  from  SL 
which  involves  Rp(x,  y )  be  £p(x ,  y).  Now 


A(V)  =>  -.(  \/  Si{x)) 

£i(x)e£L 


which  implies 


A(x)  =*►  ->(Ep(x)) 


that  is 


A(x)  =*►  3 y.y  ±  x  A  Rp(x,  y)  A  p c[y]  =  L 


Since  Rp(x,  y)  is  true 


£p(x)  =  3 y.y  ±  x  A  pc [y]  =  L 


So  we  have 


A(x)  =>  3 y.y  ±  x  A  p c[y]  =  L 


or  equivalently 


A(x)  =>■  ->l(x) 


Thus,  in  case  none  of  the  environment  conditions  in  £l  appear  unnegated  in  A(x),  A(x)  =>■ 
->l(x).  Hence  either  A(x)  =>■  l(x)  or  A(x)  and  the  lemma  is  proved.  Note  that, 

this  lemma  establishes  the  congruence  property  described  in  Section  2.2.  □ 


Remark  11.  Consider  the  full  set  of  descriptions 


p c[x\  —  L  A  ±£i(x)  A  ±£2(x)  A  •  •  •  A  ±£t(x),  where  L  e  [1.. S], 
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Given  any  concrete  state  s  and  process  c  in  a  system  V(K)  it  is  clear  that  s  |=  A  (c)  for 
some  description  A(x).  This  is  true  simply  because  we  take  every  possible  conjunction 
of  the  predicates  £i(x),, . . ,  ST(x )  with  every  possible  predicate  pc[x]  =  L.  Thus,  the 
coverage  condition  discussed  in  Section  2.2  holds  for  the  set  of  descriptions  given  above. 

The  other  property  required  to  make  environment  abstraction  sound,  namely  the  con¬ 
gruence  property  is  established  by  the  above  lemma.  Thus,  for  the  chosen  set  of  abstract 
descriptions  and  labels,  environment  abstract  is  sound. 

We  will  now  represent  descriptions  A(x)  by  tuples  of  values,  as  usual  in  predicate 
abstraction.  The  possible  descriptions  (*)  only  differ  in  the  value  of  the  program  counter 
pc  [a;]  and  in  where  they  have  negations  in  front  of  the  S(x)  predicates.  Denoting  negation 
by  0  and  absence  of  negation  by  1,  every  description  A  (A)  can  be  identified  with  a  tuple 
(pc,  ei, . . .  6t)  where  pc  is  a  control  location,  and  each  e*  is  a  boolean  variable. 

Example  4.3.3.  Consider  again  the  protocol  shown  in  Example  4.2.1.  There  is  only 
one  inter-predicate  £V\ (x,y)  =  t[x]  A  t[y].  Thus,  we  have  two  possible  relationship 
conditions  Ri(x,y)  =  t[x]  =  t[y]  and  R2(x,y)  =  t\x\  ^  t[y\.  Consequently,  we  have  6 
different  environment  predicates: 

£i(x)  =  3 y  ^  x.pc [y]  =  1  A  R^x,  y)  £±{x)  =  3y  ^  x.p c[y]  =  1  A  R2(x,  y) 

S2(x)  =  3 y  ^  x.p c[y)  =  2  A  R^x,  y)  £5(x)  =  3y  ±  x.p c[y]  =  2  A  R2(x,  y) 

£3(x)  =  3y  ^  x.pc [y]  =  3  A  Ri(x ,  y)  £6(x)  =  3y  ^  x.p c[y]  =  3  A  R2(x,  y) 

The  abstract  state  then  is  a  7-tuple  (pc,  ei, . . . ,  e$)  where  pc  refers  to  the  internal 
state  of  the  reference  process  x.  For  each  i  e  [1..6],  the  bit  et  tells  whether  there  is  an 
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environment  process  y  ^  x  such  that  the  environment  predicate  £j{x)  becomes  true.  □ 


We  build  the  abstract  model  VA  exactly  as  in  Section  2.2.  Since  the  congruence  and 
coverage  conditions  hold  for  the  set  of  descriptions  and  labels  we  have  chosen,  we  have 
the  following  corollary  of  Theorem  2.2.4: 

Corollary  3  (Soundness  of  Abstraction).  Let  'P(N)  be  a  parameterized  mutual  exclusion 
system  and  VA  be  its  abstraction.  For  an  indexed  property  '£x.(l>{x),  where  is  a 
control  condition,  we  have 

VA  [=  $(x)  =>  VK.V(K)  |=  Vx.$(x). 

4.4  Extensions  for  Fairness  and  Liveness 


The  abstract  model  that  we  have  described,  while  sound,  might  be  too  coarse  in  practice 
to  be  able  to  verify  liveness  properties.  The  reason  is  two  fold: 

(i)  Spurious  Infinite  Paths.  Our  abstract  model  may  have  infinite  paths  which  cannot 
occur  in  any  concrete  system.  Figure  4.2  shows  one  such  instance,  where  a  self-loop 
in  the  abstract  model  leads  to  a  spurious  infinite  path.  The  two  concrete  states  si 
and  s2,  such  that  .si  transitions  to  s2,  maP  to  the  same  abstract  state  s,  leading  to 
a  self-loop  involving  s.  This  self-loop  can  lead  to  a  spurious  infinite  path.  Such 
spurious  paths  hinder  the  verification  of  liveness  properties. 
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Concrete  state  s. 


Concrete  state  s2 


Figure  4.2:  Process  7  changes  its  internal  state,  but  the  abstract  state  is  not  affected.  Thus,  there  is  a  self¬ 
loop  around  the  abstract  state.  The  abstract  infinite  path  consisting  of  repeated  executions  of  this  loop  has 
no  corresponding  concrete  infinite  path. 


(ii)  Fairness  Conditions.  Liveness  properties  are  usually  expected  to  hold  under  some 
fairness  conditions.  A  typical  example  of  a  fairness  condition  is  that  every  process 
x  must  leave  the  critical  section  a  finite  amount  of  time  after  entering  it.  This  is 
expressed  formally  by  the  fairness  condition  pc  [at]  f  crit.  In  this  work,  we  will 
consider  fairness  conditions  pc  [at]  f  L,  where  L  is  a  control  location.  Liveness 
properties  are  then  expected  to  hold  on  fair  paths :  an  infinite  path  in  a  concrete 
system  V(K),  K  >  1  is  fair  only  if,  for  each  process  i,  the  fairness  condition 
pc[z]  f  L  holds  infinitely  often. 
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Monitor  Processes  for  Liveness 


To  handle  these  situations,  we  adapt  a  method  developed  by  Pnueli  et  al.  [66]  in  the 
context  of  counter  abstraction  to  our  environment  abstraction.  The  extension  to  handle 
liveness  essentially  consists  of  adding  monitor  processes.  We  first  augment  the  concrete 
system  V(K)  by  adding  monitor  processes  M(l), . . . ,  M(K)  where  each  M(i)  has  two 
sets  of  variables 

•  variables  from\ , . . . ,  f  romlT  where  T  is  the  number  of  different  environments,  and 

•  variables  to[, ,  tolT  where  T  is  the  number  of  different  environments. 

Intuitively,  the  f  rom *  and  to1  variables  keep  track  of  the  processes  coming  and  going 
out  of  the  environments  £\(i), . . . ,  £r(i)  as  viewed  from  process  i. 

Updating  Monitor  Variables 

Suppose  the  system  V{K)  is  initially  in  state  sq  and  some  process  j  changes  its  state 
resulting  in  state  s2  for  system  V(K).  Monitor  process  M(i)  then  updates  its  variables  as 
follows. 

•  Case  1:  A  process  j)  i  changes  its  state 

By  Fact  4,  we  have  uniquely  defined  environment  predicates  £p(i)  and  £q(i)  such 
that  si  (=  Ep(i,j )  and  s2  (=  Eq(i,j).  Thus  monitor  process  M(i)  sets  f  romlp  = 
true  and  to*  =  true  in  state  s2.  The  rest  of  the  f  rom1  and  to*  variables  are  set  to 
false  in  state  s2. 
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•  Case  2:  j  =  i  and  the  process  changes  its  state  using  update  transition 

For  each  environment  condition  Sp(i)  such  that  there  is  a  process  y  satisfying  Ep(i,  y ) 
in  si,  frorrip  =  true  in  state  s2.  For  each  environment  condition  £p(i)  such  that 
there  is  a  process  z  satisfying  Ep{i,  z)  in  s2,  to 1  =  true  in  state  s2.  In  all  other 
cases,  the  f  rom1  and  to 1  variables  in  s2  are  false. 

•  Case  3:  j  =  i  and  the  process  changes  its  state  using  a  guarded  transition 
In  this  case,  all  the  f  rom1  and  to1  variables  in  s2  are  false. 

Denote  the  system  obtained  by  augmenting  V(K)  with  monitor  processes  M(l), . . .  ,M(K ) 
by  VM(K).  The  states  of  VM(K)  are  given  by  tuples  of  the  form  (£i, . . . ,  Cr,M  i,  . . . ,  Mr) 
where  Cx  is  denotes  local  state  of  process  i  and  A4,  denotes  the  local  state  of  the  monitor 
process  M(i).  The  augmented  abstract  states,  given  by  tuples  of  the  form 
(pc,  ei, . . .  er,  fromi , . . . ,  fromT,  to\.. . . ,  toT),  carry  monitor  information  for  reference 
process  unchanged. 

Definition  4.4.1  (Abstraction  Mapping).  Let  VM  (K),  K  >  1,  be  an  augmented  system 
and  p  G  [1  ..K]  be  a  process.  The  abstraction  mapping  op  induced  by  p  maps  a  global  state 
s  of  VM(K)  to  an  abstract  state  (pc,  ei, . . . ,  er,  fromi ,  •  •  • ,  f  romT ,  to±, . . . ,  t,oT)  where 

•  pc  =  the  value  of  p c[p\  in  state  s 

•  for  all  Cj  we  have  e3  = 

•  Vj.  fromj  =  fromfj 

•  Vj.  toj  =  to? 
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Intuitively,  the  f  rom,  and  to  variables  keep  track  of  the  immediate  history  of  an  ab¬ 
stract  state,  that  is,  the  last  step  by  which  the  abstract  state  was  reached. 

Example  4.4.2.  Referring  to  Figure  4.2,  suppose  process  7  in  state  s\  satisfies  the  environ¬ 
ment  condition  £*(1,  7).  Then,  in  the  new  augmented  abstract  state,  variable  f  roorii  will 
be  set  to  true  to  indicate  that  a  process  satisfying  environment  condition  £*(1)  made  the 
move.  Similarly,  suppose  that  in  the  new  concrete  state  s2,  process  7  satisfies  the  environ¬ 
ment  condition  Ej(  1,  7).  Then  in  the  new  augmented  abstract  state,  the  variable  toj  is  set 
true  to  indicate  that  after  the  transition  process  7  satisfies  the  new  environment  condition 
£,(!)• 

Remark  12.  Note  that  the  abstract  model  does  not  retain  the  id  of  the  process  which  was 
responsible  for  the  transition  (process  7  in  this  case).  The  abstract  model  only  retains  the 
environment  predicates  satisfied  by  the  process  before  and  after  the  transition.  We  are 
doing  this  for  two  reasons: 

•  During  abstraction,  all  the  processes  except  the  reference  process  lose  their  identi¬ 
ties. 

•  Remembering  the  environment  predicate  satisfied  by  the  active  process  will  give  us 
a  sufficiently  precise  abstraction  to  verify  the  properties  of  interest. 

To  recapitulate,  using  the  f  rom  and  to  variables  we  are  able  to  keep  track  of  the  last  step 
of  the  route  by  which  an  abstract  state  was  reached. 

For  an  augmented  abstract  state  s,  we  denote  its  projection  consisting  of  only  the  pc 
and  e-i  variables  by  7r(s).  The  following  notation  is  also  useful:  let  s\,  s2  be  two  concrete 
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states  in  a  system  V(K)  such  that  there  is  a  transition  from  si  to  s 2.  Denote  by  si  <]  s 2  the 
index  of  the  process  whose  local  transition  lead  to  the  global  transition  from  si  to  s2,  e.g. 
process  7  in  Figure  4.2.  Recall  that  in  an  asynchronous  system,  only  one  process  at  a  time 
changes  its  state,  i.e.,  for  each  global  transition,  there  exists  a  single  process  causing  the 
transition. 

The  augmented  abstract  model  =  (S^,  P}  ■  R^,  L^)  of  the  augment  parameterized 
system  TM.(K )  is  defined  as  in  Section  2.5.2. 

Note  that  coverage  and  congruence  conditions  for  the  augmented  abstract  descriptions 
are  trivial  to  establish  given  that  the  original  abstract  descriptions  satisfy  both  conditions. 
It  follows  from  Section  2.5.2  that  adding  the  additional  monitor  information  does  not  affect 
the  soundness  of  our  abstract  model.  Thus,  we  have  f=  <T(a;)  =>■  VM(K)  |=  Vx.<3>(a;) 
where  <T(a;)  is  a  control  condition. 

Corollary  4  (Soundness  of  Augmented  Abstraction).  Let  P(N)  be  a  parameterized 
system  and  7\M(N)  be  an  augmentation  of  'P(N)  with  monitor  processes  as  described 
above  and  'Pf  be  its  augmented  abstraction.  For  an  indexed  property  V.x.fI>(.:r),  where 
<T(a;)  is  a  control  condition  we  have 

V ^  h  =>  VK-VM(K)  \=  Vx.$(x)  =►  VK.T(K)  \=  Vx.$(x) 

4.4.1  Abstract  Fairness  Conditions 

We  will  now  show  how  to  deal  with  the  two  problems  mentioned  in  the  beginning  of  this 
section,  i.e.,  (i)  spurious  paths  and  (ii)  fairness  conditions. 
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Eliminating  Spurious  Infinite  Paths. 


Recall  from  the  example  in  Figure  4.2  that  due  to  the  abstraction  there  may  exist  infinite 
spurious  paths  that  do  not  have  any  corresponding  concrete  paths,  in  particular  such  paths 
where  frorrii  is  true  infinitely  often  but  to,  is  not.  Such  a  path  cannot  correspond  to  any 
concrete  path  because: 

•  By  definition,  the  variable  f  rorrii  is  true  if  a  process  having  satisfied  £t(x)  in  the 
previous  state,  does  not  satisfy  £fx)  in  the  current  state. 

•  By  definition,  the  variable  toi  is  true  if  a  process  having  satisfied  £j(x)  in  the  previ¬ 
ous  state,  does  satisfy  £fx)  in  the  current  state. 

•  Each  concrete  system  has  only  a  finite  number  of  processes. 

•  Thus,  for  a  finite  number  of  processes  to  make  frorrii  true  infinitely  often,  it  is 
necessary  for  toi  to  be  true  infinitely  often  as  well. 

Therefore,  to  eliminate  the  spurious  infinite  paths  arising  from  loops  described  above,  we 
add  for  each  %  e  [1..T]  a  compassion  condition  [66]  (from,,  to,')  which  says  if  frorrii  = 
true  holds  infinitely  often  in  a  path,  then  toi  =  true  must  hold  infinitely  often  as  well. 
We  will  denote  this  set  of  fairness  conditions  by  FI. 

Adding  Abstract  Fairness  Conditions. 

Assume  that  in  the  concrete  model  each  process  has  a  fairness  condition  of  the  form  pc  f 
L.  This  means  that  a  process  is  not  allowed  to  stay  at  control  location  L  forever.  To  abstract 
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the  concrete  fairness  condition  we  have  to  find  two  sets  of  abstract  fairness  conditions,  one 
for  the  reference  process  I  \  and  the  other  for  the  environment  processes. 

Fairness  conditions  for  the  environment  processes.  The  abstract  model  maintains  the 
properties  of  the  environment  processes  only  in  terms  of  the  environment  predicates.  Thus, 
the  concrete  fairness  conditions  on  the  environment  processes  have  to  be  translated  to 
fairness  conditions  involving  the  environment  predicates. 

More  precisely,  given  a  fairness  condition  pc  f  L,  we  need  to  consider  those  environ¬ 
ment  conditions  that  require  the  environment  process  to  be  in  control  location  L,  i.e.,  those 
environment  conditions  Efx,y )  where  Efx,y )  =  Rj{x,y)  A  p c[y]  =  L.  For  each  such 
Efx,  y)  we  add  the  fairness  condition 


-i (frorrii  =  false  A  e*  =  1). 

This  condition  excludes  the  cases  where  along  an  infinite  path,  the  set  of  processes  sat¬ 
isfying  the  environment  condition  Ei(x,  y)  is  non-empty  (i.e.,  e*  =  1)  and  none  of  these 
processes  ever  changes  its  state  (i.e.,  frorrii  =  false).  We  will  denote  this  set  of  fairness 
conditions  by  F2 

Fairness  conditions  for  the  reference  process.  The  abstract  fairness  condition  correspond¬ 
ing  to  the  reference  process  is  given  by  pc  f  L.  This  expresses  the  requirement  that  the 
control  location  of  the  reference  process  is  not  L  infinitely  often.  We  will  denote  this  set 
of  fairness  conditions  by  F3. 
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4.4.2  Soundness  in  the  Presence  of  Fairness  Conditions 


Now  we  will  show  that  adding  these  fairness  conditions  do  not  rule  out  any  legitimate 
paths  in  the  abstract  model.  Thus,  the  augmented  abstracted  model  will  be  sound. 

We  are  usually  interested  in  verifying  single  index  liveness  properties  of  the  form 

Vx.AG (4>(x)  — >  Fip(x)). 

For  example,  for  mutual  exclusion  protocols,  the  standard  liveness  property,  which 
says  if  process  is  trying  to  get  into  the  critical  section  it  eventually  will,  can  be  written  as 

Vo;.  AG  (pc  [a;]  =  try  — >  F(pc[x]  =  crit)). 

The  following  theorem  claims  that,  for  single  index  liveness  properties,  the  augmented 
abstract  model  that  we  constructed  is  sound. 

Theorem  4.4.3  (Soundness  of  Abstraction).  Let  'P(K)  be  a  parameterized  system  with 
fairness  constraint  pc  f  L  and  be  its  augmented  abstraction  using  the  abstract  fair¬ 
ness  and  compassion  conditions.  Given  the  single-indexed  liveness  property  V.x.T(.x), 
rf  h  »(  x)  under  the  abstract  fairness  conditions  implies  V(K)  f=  'ix.(l>(x)  under  the 
concrete  fairness  condition. 

The  augmented  abstraction  thus  obtained  is  precise  enough  to  prove  liveness  properties 
for  the  two  mutual  exclusion  protocols  we  considered.  The  following  section  gives  a  proof 
of  the  soundness  theorem. 
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4.4.3  Proof  of  Soundness 


Given  concrete  fairness  condition  pc[x]  f  L,  the  augmented  abstract  model  has  three  sets 
of  fairness  conditions: 

FI.  For  each  i  e  [1..T],  the  compassion  condition  ( frorrii ,  toi )  saying  that  if  frorrii  = 
true  infinitely  often  along  an  abstract  path  then  to*  =  true  infinitely  often  as  well. 

F2.  The  fairness  conditions  ->  (f  rorrii  =  true  A  e%  =  1  j  for  each  i  such  that  the  environ¬ 
ment  condition  Efx,  y)  requires  process  y  to  be  in  control  location  L. 

F3.  The  fairness  condition  pc  f  L  requiring  that  the  reference  process  satisfies  the 
concrete  fairness  condition  pc  M  ^  L. 

The  proof  of  Theorem  4.4.3  relies  on  the  following  lemma. 

Lemma  4.4.4.  Let  V(K )  be  a  concrete  system  with  process  c  and  let  a  =  g0,  g1, . . .  be  a 
fair  path  under  the  fairness  constraint  pc  [a:]  f  L.  Then  the  augmented  abstract  model  V"} 
has  a  path  0  =  go,  gi, . . .  such  that 

1.  for  each  i  >  0,  tt (gf)  =  ac(gi),  and 

2.  the  abstract  fairness  conditions  FI,  F2,  F3  hold  for  a. 

Proof  The  lemma  claims  that  corresponding  to  every  concrete  fair  path  and  a  given  ref¬ 
erence  process  c  there  is  an  abstract  fair  path  in  the  augmented  abstract  model.  In  other 
words,  our  abstract  fairness  conditions  do  not  remove  any  fair  paths. 
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Given  a  concrete  fair  path  a  of  system  Vi  I\)  we  construct  an  abstract  fair  path  a  as 
follows: 

•  For  the  first  state  g0  we  require  n  (g0)  =  ac(g0),  and  the  from,  and  to,  variables  can 
have  any  value. 

•  For  each  g„  i  >  0  we  require  adth)  =  n(gi),  and  the  toi,  and  f  rom t  are  set  accord¬ 
ing  to  the  definition  of  the  augmented  abstract  transition  relation  in  Section  4.4. 

Thus,  item  1  of  the  lemma  is  satisfied  by  construction.  The  fact  that  a  is  a  valid  trace 
in  the  abstract  model  also  follows  by  construction. 

We  will  now  show  that  if  o  is  a  fair  path  then  a  satisfies  the  abstract  fairness  conditions 
as  well.  We  consider  the  different  ways  in  which  a  might  fail  to  satisfy  the  abstract  fairness 
conditions  and  argue  that  each  case  leads  to  a  contradiction. 

Violation  of  FI.  Assume  towards  a  contradiction  that  a  violates  the  compassion  condition 
( fromk ,  tok)  for  some  k  G  [1..T],  i.e.,  there  exists  an  i  >  0  such  that 

•  f  romk  is  true  infinitely  often  in  states  gt,  gi+ 1, 

•  but  tok  =  false  in  all  the  states  gt,  g,+ 1 , . . . 

There  are  two  cases  in  which  f  romk  holds  true  in  a  certain  state  eg: 

(a)  A  process  y  satisfying  enviroment  condition  Ek(c,  y )  in  r//_]  moves  to  a  new  envi¬ 
ronment  in  gi. 


(t) 

(*) 
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(b)  In  state  <#_i,  there  is  a  process  y  satisfying  the  environment  condition  Ek(c.  y),  and 
the  reference  process  c  makes  an  update  transition  from  gi_i  to  gt. 

For  fromk  to  be  true  infinitely  often,  either  case  (a)  or  case  (b)  has  to  hold  infinitely 
often.  We  will  show  that  both  cases  lead  to  a  contradiction.  First  assume  case  (a).  As  there 
are  only  a  finite  number  of  processes,  fromk  being  true  inifinitely  often  requires  tok  to  be 
true  infinitely  often  as  well.  This  contradicts  (*). 

In  case  (b)  the  fromk  is  true  in  a  state  gt  because  the  reference  process  made  an  update 
transition  and  there  was  process  y  satisfying  the  environment  Ek(c,  y)  in  state  gi-\.  After 
such  an  update  transition  we  again  have  two  cases: 

(b.l)  There  is  a  process  y  satisfying  the  condition  Ek(c,y)  in  state  gt,  i.e.,  ek  is  1  in  gt. 
In  this  case  tok  is  set  to  true  by  our  definition  of  the  augmented  abstract  transition 
relation  in  Section  4.4,  or 

(b.2)  there  is  no  process  y  satisfying  the  condition  Ek(c,  y)  in  state  gx  i.e.,  ek  =  0. 

The  former  case  (b.l)  immediately  contradicts  the  assumption  (*).  In  the  latter  case 
(b.2),  if  ek  continues  to  be  0,  then,  by  definition,  fromk  cannot  be  true  again.  This 
contradicts  the  assumption  (f). 

Thus,  we  have  proved  that  the  compassion  condition  (/rom*,  tty)  cannot  be  violated 
in  the  abstract  trace  a. 

Violation  of  F2.  Assume  towards  a  contradiction  that  a  violates  the  fairness  condition 
-i (fromk  =  false  A  ek  —  1)  where  the  environment  condition  Ek(x,  y)  requires  process 
y  to  be  in  control  location  L.  That  is,  there  exists  an  i  >  0  such  that  gj  \=  fromk  = 
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false  A  efc  =  1  for  all  j  >  i.  In  other  words,  in  the  concrete  trace  in  all  the  states 
gj,  gj+ 1, ...  of  the  concrete  trace  there  is  a  process  y  satisfying  the  environment  condition 
Ek(c,  y),  and  this  process  y  never  leaves  the  environment  corresponding  to  Ek(x,  y).  Since 
Ek(x,y )  requires  process  y  to  be  in  control  location  L,  process  y  violates  the  concrete 
fairness  condition  pc[slf]  0  L,  and  thus,  the  assumption  of  the  lemma. 

Violation  of  F3.  Assume  towards  a  contradiction  that  a  violates  the  fairness  condition 
pc  0  L,  i.e.,  there  is  an  i  >  0  such  that  for  all  g3 ,  j  >  i,  9j  1=  PC  =  L  holds.  This  is 
possible  only  if  process  c  stays  in  control  location  L  after  concrete  state  gu  thus  violating 
the  concrete  fairness  condition,  and  thus,  the  assumption  of  the  lemma. 

We  see  that  in  all  the  three  cases  we  are  led  to  a  contradiction.  Consequently,  the 
abstract  trace  a  does  not  violate  any  abstract  fairness  conditions.  □ 

Theorem  4.4.3.  Consider  a  single  index  liveness  property  Vx. AG (4>(x)  — >  F ip(x)).  As¬ 
sume  that 

A  h 

under  abstract  fairness  conditions,  and  assume  towards  a  contradiction  that  there  is  a  fair 
path  a  =  g0)gl , ...  in  system  V{K)  such  that  a  ^  <p(c)  — >■  F-0(c)  for  some  process 
c.  Thus,  there  exists  an  i  >  0  such  that  gj  \=  0(c)  and  g j  \/=  0(c)  for  all  j  >  i.  By 
Lemma  4.4.4  there  is  a  fair  abstract  path  o  =  g0,  g\, . . .  such  that  for  all  k,  n(gk)  =  ac(gk). 
By  definition,  gj  \—  c>(x)  and  for  all  j  >  i,  gj  0  0(x).  Thus,  there  is  a  fair  path  a  in  the 
abstract  model  Vf  that  violates  the  liveness  property  ^(.x),  contradicting  our  assumption 
that  V*\=${  x).  This  completes  our  proof.  □ 
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4.5  Computing  the  Abstract  Model 


We  have  thus  far  presented  the  theoretical  description  of  the  abstract  model  and  the  prop¬ 
erties  it  satisfies.  We  have  not  described  how  to  actually  obtain  such  an  abstract  model 
from  a  given  parameterized  system.  In  this  section,  we  will  show  how  to  construct  the 
abstract  model. 

Computing  the  abstract  model  is  evidently  complicated  by  the  fact  there  is  an  infinite 
number  of  concrete  systems.  Further,  it  is  well  known  that  in  predicate  abstraction  and 
related  methods,  computing  the  exact  abstract  model  is  computationally  very  expensive. 
Instead  of  finding  the  most  precise  abstract  model,  we  find  an  over- approximation  of  the 
abstract  model.  We  consider  each  concrete  transition  statement  of  the  program  separately 
and  over-approximate  the  set  of  abstract  transitions  it  can  lead  to.  The  union  of  these 
sets  will  be  the  abstract  transition  relation.  A  concrete  transition  can  either  be  a  guarded 
transition  or  an  update  transition.  Each  transition  can  be  executed  by  the  reference  process 
or  one  of  the  environment  processes.  Thus,  there  are  four  cases  to  consider: 


Active  process  is  . . . 

guarded  transition 

update  transition 

. . .  reference  process 

Case  1 

Case  2 

. . .  environment  process 

Case  3 

Case  4 

We  will  show  how  we  abstract  in  each  of  these  cases  and  argue  why  the  computed 
abstract  transition  is  an  over-approximation.  Before  we  begin  we  recall  the  following 
facts: 

Fact  7.  For  any  two  environment  predicates  Efx,  y )  and  Ej{x ,  y ),  i  ^  j  E,(x.  y )  =>- 
~'Ej(x,y). 
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Fact  8.  Given  any  formula  G(x,  y )  involving  inter-predicates  £V  \  (x,  y  ). . . . .  £Vr{x,  y) 
either  Efx,  y)  ->G(x,  y)  or  Efx,  y)  Q{x,  y). 

We  now  introduce  some  useful  notation.  The  environment  condition  Efx,  y)  =  y  f 
x  A  Rj(x,  y )  A  pc [y\  =  L  will  be  denoted  by  E^j^  (x,  y).  The  variables  and  formulas  cor¬ 
responding  to  this  environment  condition  are  referred  to  using  the  same  subscript  {j,  L } , 
e.g.,  the  corresponding  environment  predicate  is  referred  to  as  £(Jjj)(x)  and  the  corre¬ 
sponding  abstract  variable  is  e^)L).  The  set  of  all  environment  conditions  E(:hL)  (x,  y)  is 
referred  to  as  El. 

4.5.1  Case  1:  Guarded  Transition  for  Reference  Process 


Consider  first  the  case  of  guarded  transitions  being  executed  by  the  reference  process. 
Consider  the  guarded  transition  statement  to' 

Li  :  if  Votr  ^  slf.£/(slh  otr)  then  goto  L2  else  goto  L3 

Suppose  the  reference  process  is  executing  this  guarded  transition  statement.  If  at 
least  one  of  the  environment  processes  contradicts  the  guard  Q  then  the  reference  process 
transitions  to  control  location  L3,  i.e.,  the  else  branch.  Otherwise,  the  reference  process 
goes  to  Lo.  We  will  now  formalize  the  conditions  under  which  the  if  and  else  branches  are 
taken. 

Definition  4.5.1  (Blocking  Set  for  Reference  Process).  Let  =  Votr  f  slf.ClsIf.  otr)  be 
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a  guard.  We  say  that  an  environment  condition  Ei(x,  y )  blocks  the  guard  CV  if  Et(x.  y )  =>- 
-i Q(x,  y).  The  set  Bx(<3)  of  all  indices  i  such  that  E^x,  y)  blocks  <£  is  called  the  blocking 
set  of  the  reference  process  for  guard  . 

Note  that  by  Fact  6,  either  E7{x,  y)  y)  or  E7(x ,  y)  G{x,  y)  for  every 

environment  E7(x,  y).  The  intuitive  idea  behind  the  definition  is  that  £>x(£f)  contains  the 
indices  of  all  environment  conditions  which  enforce  the  else  branch. 

We  will  now  explain  how  to  represent  the  guarded  transition  tG  in  the  abstract  model: 
we  introduce  an  abstract  transition  from  s\  =  (pc,  e3, ..,  eT,  frorrii, fromT,  toi,  ..,toT) 
to  s2  =  (pc',  el7 eT,  f  rorn\ , f  rom'T ,  fo\, .. ,to'T )  if 

GR1.  pc  =  Lu  i.e.,  the  reference  process  is  in  location  L  i, 

GR2.  one  of  the  following  two  conditions  holds: 

•  Then  Branch:  Vi  G  Bx( &).  (e*  =  0)  and  pc'  =  L2,  i.e.,  the  guard  is  true  and 
the  reference  process  moves  to  control  state  L2. 

•  Else  Branch:  ->Vi  G  Bx(&).  (e*  =  0)  and  pc;  =  L3,  i.e.,  the  guard  is  false  and 
the  reference  process  moves  to  control  state  L3. 

GR3.  and  all  the  variables  froin\ ....  from'T  and  lo\ ....  to'T  are  false,  expressing  that 
none  of  the  environment  processes  changes  its  state. 

Together,  these  three  conditions  can  be  viewed  as  an  transition  invariant  Ix(ta )  be¬ 
tween  the  current  and  the  next  abstract  states.  The  following  fact  shows  that  the  set  of 
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abstract  transitions  represented  by  Ix(tG )  is  indeed  an  over-approximation  of  the  set  of 
abstractions  that  tG  gives  rise  to. 

Lemma  4.5.2.  Let  si  be  a  state  in  a  concrete  system  V(K),  and  suppose  that  a  process 
c  executes  a  guarded  transition  tG  which  leads  to  state  s2.  Then  the  abstract  states  s\  = 
ac(si)  and  s 2  =  ac(s2)  satisfy  the  invariant  Ix{tG). 

Proof  Assume  there  is  a  guarded  transition  tG  from  state  si  to  s2  with  the  reference  pro¬ 
cess  c  as  the  active  process.  There  are  two  cases  to  consider: 

•  The  concrete  guard  was  true  in  state  si  and  process  c’s  new  control  location  in 
state  .S' 9  is  L2.  By  Fact  6,  each  environment  condition  E,(x.  y)  either  implies  the 
guard  condition  G(x,y )  or  its  negation.  Any  process  y  satisfying  an  environment 
Ej(x,y),j  G  B'r((4)  would  block  the  guard  Qic,  y).  In  other  words,  for  the  then 
branch  to  be  taken,  in  state  si  every  concrete  process  y  f  c  must  have  satisfied  only 
environment  conditions  which  are  not  mentioned  in  the  blocking  set  Bx(f&).  Thus, 
the  condition  Vi  G  Bx{(4).el  =  0  is  true  in  .§1  and  the  abstract  model  transitions  to 
state  .§2. 

•  The  concrete  guard  was  false  in  state  si  and  process  c’s  new  control  location  in  state 
* 2  is  L3.  By  Fact  6,  each  environment  condition  Efx,y )  either  implies  the  guard 
condition  G(x,  y)  or  its  negation.  For  the  else-branch  to  be  taken,  there  must  be  at 
least  one  process  y  in  state  s\  satisfying  an  environment  E:j(x,  y),j  G  BxifS)  so  that 
the  guard  Q{c,  y)  evaluates  to  false.  Thus,  the  abstract  condition  Vi  G  B'r{(.^).el  =  0 
is  false  for  si,  and  the  abstract  model  still  transitions  to  state  s2- 
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□ 


4.5.2  Case  2:  Guarded  Transition  for  Environment  Processes 


Suppose  that  the  guarded  transition  t-c 

L1  :  if  Votr  ^  slf.£(slf,  otr)  then  goto  L2  else  goto  L3 

is  executed  by  a  concrete  process  y  satisfying  the  environment  condition  E^Ll)(x,y). 
The  active  process  thus  switches  from  environment  condition  E^l^x,  y)  to  environment 
condition  E^L2)  (x,  y)  or  E^L 3)  (x,  y).  Note  that  in  a  guarded  transition,  only  the  pc  of  the 
active  process  changes. 

We  will  now  define  a  blocking  set  for  this  environment  condition  y)  as  fol¬ 

lows.  The  difference  from  Definition  4.5.1  is  that  the  guard  for  process  y  can  be  blocked 
either  by  the  reference  process  or  by  another  environment  process.  Therefore  we  need  to 
distinguish  two  cases  in  the  definition. 

Definition  4.5.3  (Blocking  Set  for  Environment  E^Ll)(x,y)).  Let  Sf(slf)  =  Votr  ^ 
slf.£(slf.  otr)  be  a  guard.  We  say  that 


1 .  An  environment  condition  Ej  (x,  z)  blocks  the  guard  for  process  y  satisfying  E{lJj^  (x,  y) 
if 


E{i,Ll)(x,y)  A  Ej(x,z)  =>  ~>G(y,z). 


Let  (G)  be  the  set  of  all  such  indices  j. 
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2.  The  control  location  L  of  the  reference  process  x  blocks  the  guard  for  process  y 
satisfying  E(iM)(x,y)  if 

E(t,Li)(x>y) A  pcM  =  L  =>  ^0{y,x). 

Let  B'ft  Li)(Q)  be  the  set  of  all  such  control  locations  L. 

Note  that  we  consider  the  guards  Q(y,  z)  and  Q(y ,  x)  because  y  is  the  active  process, 
i.e.,  y  executes  the  transition.  We  define  the  abstract  guard  Sf®  for  guard  (f(slf)  =  Votr  ^ 
slf.f/(slf.  otr)  and  the  environment  condition  Ei(x ,  y)  as  follows: 

Vj  G  =  0)  A  pc  $BfitLl)(&). 

Since  the  transition  starts  in  control  location  Li  and  the  active  process  is  an  environment 
process,  we  will  describe  the  abstract  transition  invariant  J*’Ll  (tG)  for  each  E^Ll)  (x,  y)  G 
ELl  by  a  list  of  conditions  as  in  Case  1.  The  abstract  transition  invariant  for  Case  2  will 
then  be 

I“(tc)  =  V  C'lte). 

Consider  one  such  E^Ll)(x,y)  G  ELl.  The  abstract  transition  relation  ry’Ll(tc)  has  a 

transition  from  s  =  (pc,  ei, . . . ,  ex,  fromi, . . . ,  frorriT,  toi, . . . ,  tor) 

to  s'  =  (pc',  e’T,  from [, . . . ,  from'T,  to[ , . . . ,  to'T)  if  the  following  conditions  hold: 

GE1.  e(j)Ll)  =  1,  that  is,  there  is  a  process  satisfying  environment  condition  E(iyLl)(x,  y). 

GE2.  from[lM)  =  true,  that  is,  the  active  process  switches  from  environment  condition 
y)  to  some  other  environment  condition. 
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GE3.  e'u  Li)  G  {0, 1},  that  is,  due  to  the  active  process  switching,  there  may  or  may  not 
remain  a  process  satisfying  the  environment  condition  E^Ll) (x.  y). 

Depending  on  the  value  of  the  abstract  guard,  one  of  the  following  two  cases  holds: 

1.  The  guard  (3l  is  true,  i.e.,  s  \=  and  either 

•  the  then  branch  is  taken,  i.e.,e^  =  1  and  to^L2)  =  true,  or 

•  the  Else  branch  is  taken,  i.e.,  e'{-  La)  =  1  and  to^3)  =  true. 

We  will  explain  this  case  below. 

2.  The  guard  is  false,  i.e.,  s  and  the  Else  branch  is  taken,  i.e.,  e'u  =  1, 

tO(i,L3)  =  true. 

GE4.  The  rest  of  the  ej  variables  are  the  same  in  s  and  s'. 

GE5.  The  from']  and  to'-  variables  are  set  to  false  by  default  unless  they  are  set  to  true 
by  one  of  the  above  conditions. 

The  reason  for  the  two  else-branches  is  the  fact  that  knowledge  about  a  single  process 
suffices  to  block  the  guard,  while  knowledge  about  all  processes  is  necessary  to  make 
sure  the  guard  is  not  blocked.  The  environment  predicates  Ej  (x.  y )  only  contain  accurate 
information  about  the  relationship  between  the  data  variables  of  the  reference  process  x 
and  the  data  variables  of  environment  process  y.  If  it  follows  already  from  this  partial 
information  that  the  guard  is  violated  then  the  Else  branch  is  enforced.  If  however  the 
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guard  cSl  is  true,  this  may  be  due  to  lack  of  information  in  the  abstract  predicates,  and  we 
over-approximate  the  possible  abstract  transitions. 

Note  that  Case  2  is  different  to  Case  1,  because,  in  Case  1,  the  reference  process  makes 
the  guarded  transition,  while  in  Case  2,  an  environment  process  makes  the  transition.  In 
case  of  the  reference  process,  our  abstraction  maintains  the  relationship  of  its  data  variables 
to  the  other  variables.  In  case  of  an  environment  process,  we  only  know  the  relationship 
of  its  data  variables  to  the  reference  process. 

Lemma  4.5.4.  Let  si  be  a  state  in  a  concrete  system  'P(K),  and  let  c  be  a  process  used 
as  reference  process.  Suppose  that  a  process  d  f  c  executes  a  guarded  transition  tG  that 
leads  to  state  s2.  Then  the  abstract  states  ac(si)  and  ac(s2)  satisfy  the  invariant  Iy(tG). 

Proof  This  follows  directly  from  the  construction  of  the  transition  invariant  Iy(tc)-  □ 

4.5.3  Case  3:  Update  Transition  for  Reference  Process 


Consider  the  case  where  the  reference  process  is  executing  an  update  transition  tG: 


Li  :  for  all  otr  f  slf  if  T (slf,  otr)  then  Uk  ■—  $(otr) 

goto  L2 

Recall  that  each  process  has  data  variables  u\, . . . 4  Ud-  We  denote  the  next  state  value 
of  each  variable  um  by  u'm. 


152 


When  the  reference  process  x  changes  the  value  of  its  data  variables,  the  valuations  of 
the  environment  predicates  E\(x) . . .  Et{x)  will  change.  For  a  process  y  satisfying  envi¬ 
ronment  condition  Efx,  y )  we  need  to  figure  out  the  possible  new  environment  conditions 
Ej(x,  y)  that  y  might  satisfy  after  the  reference  process  x  has  executed  the  update  transi¬ 
tion.  The  set  of  possible  new  environment  conditions  for  process  y  is  called  the  outset  0{ 
for  condition  Efx,  y).  (Technically,  the  outset  is  the  set  of  the  indices  of  these  environ¬ 
ment  conditions.)  We  will  now  explain  how  to  compute  the  outset. 

Denote  by  T(x,  y)  the  formula 

T(x,y)Au'k[x]  :=(f>(y)  V  ^T(x,  y)  A  u'k[x\  :  =  uk[x\. 

We  call  T (x,y)  the  update  formula.  Given  the  update  formula  we  find  what  possible 
inter-predicates  involving  u'k[x],uk[y\  can  be  true.  Formally,  the  set  Cl{uk)  of  these  inter¬ 
predicates  is  given  by  all  formulas  uk[x\  -<  uk[y]  where  -<e  {<,>,=}  such  that 

uk[x\  -<  uk[y\  A  T(x,  y)  is  satisfiable. 

Thus,  C'lk  contains  all  possible  ways  uk[x\  and  uk[y]  can  relate  to  each  other  after  the 
update.  The  possible  relationships  between  uk[x\  and  uk[y]  might  change  again  when,  in 
the  course  of  evaluating  the  update  transition,  x  repeatedly  updates  its  uk  value  by  looking 
at  other  processes. 

Suppose  x  looks  at  another  process  z  and  updates  its  uk[x\  value  again.  We  now  find 
the  set  C2(uk )  of  possible  relationships  between  uk[x]  and  uk[y]  after  the  new  update 
involving  process  z  under  the  assumption  that  a  relation  from  Cl  (  »/,.)  holds  before  the 
update. 
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Thus,  the  new  set  C2(uk )  of  relationships  is  given  by  all  formulas  uk[x]  -<  uk  [y]  where 
AG  {<,>,=},  such  that 

u'k[x]  -<  Uk[y\  A  T(x,  z)  A  ip(x,  y)  is  satisfiable  and  ip(x,  y)  G  C 1(uk). 

Note  that  Cl{uk )  C  C2{uk )  because  the  definition  of  T(x,  z)  allows  the  possibility  that 
the  value  of  uk[x]  remains  unchanged.  We  similarly  compute  sets  C3(uk),  CA(uk)  ■  ■  ■  until 
a  fixpoint  is  reached.  Since  the  number  of  possible  inter-predicates  is  finite,  a  fixpoint 
always  exists;  for  simple  inter-predicates  involving  and  =,  the  fixpoint  computation 
takes  three  iterations  at  the  most.  We  denote  this  fixpoint  by  C(uk ). 

In  the  environment  condition  Ei(x,y),  let  6  be  the  inter-predicate  that  describes  the 
relation  between  uk[x]  and  Uk[y].  Consider  the  set  of  environment  conditions  Ej(x,  y)  that 
are  obtained  from  Et(x,  y)  by  replacing  9  by  a  formula  in  the  fixpoint  C{uk )  -  the  indices 
of  these  environment  conditions  constitute  the  outset  Oj  of  E,  (x.  y).  Correspondingly,  the 
inset  Ik  C  {1..T }  for  environment  condition  Ek{x ,  y)  consists  of  all  j  such  that  k  G  Oj. 

We  denote  the  abstract  transition  invariant  corresponding  to  the  concrete  update  tran¬ 
sition  tu  by  /;'p(C/j.  I*p(tu)  has  a  transition  from  the  abstract  state 
s  =  (PC,  ei, . . . ,  ex,  f  rorrii , . . . ,  frorriT ,  to\, . . . ,  tor)  to  the  abstract  state 
s'  =  (pc',  e[, . . . ,  e'T,  f  rom\ , . . . ,  from'T ,  t,o\ , . . . ,  to'T)  if  the  following  conditions  hold: 

UR1.  pc  =  Lu  i.e.,  the  reference  process  is  in  control  location  L\  before  the  transition. 

UR2.  pcr  =  L2,  i.e.,  the  reference  process  moves  to  control  location  L2. 

UR3.  \/k  G  [l..T\.(ek  =  1  3j  G  Ok.e '■  =  1),  i.e.,  if  there  was  a  process  in  environ¬ 
ment  Sk(x)  before  the  transition  then  there  must  be  a  process  in  one  of  the  outset 
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environments  Ok  of  Ek(x,  y )  after  the  transition. 


UR4.  Vj  G  //,.(e?  =  0  =>-  e'k  =  0),  i.e.,  if  there  is  no  process  satisfying  the  inset  environ¬ 
ments  Ik  of  environment  Ek(x,  y )  before  the  transition  then  after  the  transition  there 
can  be  no  process  in  environment  Ek(x,  y). 

UR5.  \fk  G  [l..T].(e'k  =  1  tok  =  true).  The  variable  to'k  indicates  if  after  the 
transition  there  is  a  process  satisfying  Ek(x,  y). 

UR6.  V/e  G  [l..T].(efe  =  1  fromIk  =  true).  The  variable  fromIk  indicates  if  before 
the  transition  there  is  a  process  satisfying  Ek{x ,  y). 

Lemma  4.5.5.  Let  .Si  be  a  state  in  a  concrete  system  V(K),  and  suppose  that  a  process  c 

executes  an  update  transition  tjj  which  leads  to  state  s 2.  Then  the  abstract  states  ac(si) 

and  ac(s 2)  satisfy  the  invariant  I*p(tjj)- 

Proof  This  follows  directly  from  the  construction  of  the  invariant  I*p(tu).  □ 

4.5.4  Case  4:  Update  Transition  for  Environment  Processes 


This  case  is  quite  similar  to  Case  3.  Recall  that  E^Ll)(x,  y)  denotes  the  environment 
condition  y  f  x  A  Rfx,  y)  A  p c[y]  =  L\.  Consider  the  case  where  a  generic  process  y 
satisfying  environment  E^Llfx,  y)  is  executing  an  update  transition  tjj'. 


155 


L i  :  for  all  otr  7^  slf  if  T (slf,  otr)  then  uk  ■—  <f>(otr) 

goto  L2 

After  the  update  transition  process  y  will  have  a  new  control  location  and  also  the  rela¬ 
tionship  of  its  data  variables  to  those  of  the  reference  process  x  will  have  changed.  The  out¬ 
set  O^Li)  for  environment  E^Ll){x,  y )  will  consist  of  all  those  environments  2)  (a;,  y) 
that  process  y  may  satisfy  after  the  update  transition.  To  compute  the  outset  Oul^  we 
proceed  as  follows.  As  in  the  previous  case,  we  find  a  fixpoint  C{uk)  that  contains  the 
possible  relationships  between  uk[x\  and  uk[y].  The  initial  set  of  relationships  G'1  (uk)  is 
the  set  of  all  uk[x]  -<  uk[y],  AG  {<,>,=}  such  that 

T (y,  x )  A  uk[x]  A  u'k [y\  is  satisfiable 

where  T (y,  x)  is  the  update  condition  as  defined  in  Section  4.5.3.  Note  that  we  consider 
T (y,  x)  (and  not  T(a:,  y )  as  in  the  previous  section)  because  y  is  the  active  process.  As  y 
updates  its  uk  variable  repeatedly,  the  relationship  between  uk[x],uk[y]  will  also  change. 
To  compute  all  the  possible  relationships  we  use  an  approach  similar  to  the  fixpoint  com¬ 
putation  in  Case  3.  Thus,  we  find  the  set  C2(uk )  of  all  uk[x] |  -<  uk[y\,  -<e  {<,  >,  =}  such 
that 

T (y,  z )  A  uk[x ]  -<  u'k[y\  A  ip(x,  y)  is  satisfiable 

where  ii(x,y)  G  Cl{uk).  We  similarly  compute  C3(uk),  C4(uk), . . .  until  we  reach  a 
fixpoint  C(uk). 

In  the  environment  condition  EuLl\ (x.  y),  let  6  be  the  inter-predicate  that  describes  the 
relation  between  uk[x]  and  uk[y\.  Consider  the  set  of  environment  conditions  E(J:L^  ( x ,  y) 
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that  are  obtained  from  E^tLl)(x,  y)  by  replacing  9  by  a  formula  in  the  fixpoint  C(uk )  and 
replacing  the  condition  pc[y]  =  L1  by  pc|y]  —  L2  -  the  indices  of  these  environment 
conditions,  written  as  pairs  (j,  L2),  constitute  the  outset  0^Ll)  of  E^Ll){x,  y). 

Since  the  transition  starts  at  control  location  L1  and  a  generic  process  executes  it, 
we  will  describe  the  abstract  transition  Iy’Ll^^,L2\tu)  for  each  environment  condition 
E(iM)(xi  V )  and  each  (j?  L2)  G  0(i,L i).  The  abstract  transition  I^p(tu)  for  Case  4  will  be 

V  V 

E(i,Ll)(X’y)  C?>L2  )e°(i:Ll) 

As  above,  we  will  define  Iy'Ll^^'L2\tu)  by  a  list  of  conditions.  Iy'Li)'^'L2\tu)  has  a 

transition  from  s  =  (pc,  ei, . . . ,  ey,  f  rom i, . . . ,  fromr,  to\, . . . ,  tor) 

to  s'  =  (pc7,  e\, . . . ,  e'T,  from [, . . . ,  from'T,  t,o\ , . . . ,  fo^)  if  the  following  conditions  hold: 

UE1.  pc  =  pc',  i.e.,  the  reference  process  does  not  move. 

UE2.  e(i)Ll)  =  1,  i.e.,  there  is  a  process  in  environment  E^Ll^x^  before  the  transition. 

UE3.  eC  L))  =  1,  i.e.,  there  is  a  process  in  environment  E(j  L2^x  y)  after  the  transition. 

UE4.  e]  =  e/  for  l  ^  {( i,L1 ),  (j,  L2)},  i.e.,  all  the  e  variables  except  e',-^  and  e'(j 
remain  the  same. 

UE5.  from 7  Li)  =  true  and  the  rest  of  the  from[  variables  are  false,  i.e.,  only  a  process 
satisfying  environment  condition  E(itLl){x,  y)  moves,  and  no  other  process  moves. 
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UE6‘  toU,L2)  =  true  and  the  rest  of  the  to\  variables  are  false,  i.e.,  only  the  environment 
condition  E^Ll)(x,  y)  has  a  new  process  and  no  other  environment  condition  has  a 
new  process. 

Lemma  4.5.6.  Let  si  be  a  state  in  a  concrete  system  V(K),  and  let  c  be  the  process  used 
as  reference  process.  Suppose  that  a  process  d  f  c  executes  an  update  transition  tu  that 
leads  to  state  S2-  Then  the  abstract  states  ac(si)  and  ac(s2)  satisfy  the  invariant  Ifftu). 

Proof  This  follows  directly  from  the  construction  of  the  invariant  iv  (tu).  □ 


4.6  Experimental  Results 

In  most  mutual  exclusion  protocols,  the  predicates  appearing  in  the  guards  are  simple 
linear  expressions  involving  the  and  =  operators.  Thus,  the  decision  problems  that 
arise  during  abstraction  are  simple  and  are  handled  by  our  abstraction  program  internally. 
We  verified  the  safety  and  liveness  properties  of  Szymanski’s  mutual  exclusion  protocol 
and  Lamport’s  bakery  algorithm.  These  two  protocols  have  an  intricate  combinatorial 
structure  and  have  been  used  widely  as  benchmarks  for  parameterized  verification.  For 
safety  properties,  we  verified  that  no  two  processes  can  be  present  in  the  critical  section  at 
the  same  time.  For  liveness,  we  verified  the  property  that  if  a  process  wishes  to  enter  the 
critical  section  then  it  eventually  will. 

Note  that  these  protocols  have  been  analyzed  by  other  methods,  but  in  most  cases  ei¬ 
ther  the  protocols  have  been  simplified  (in  addition  to  the  atomicity  assumption)  or  the 
method  cannot  handle  both  protocols.  Pnueli  et  al.  [66]  have  verified  Szymanski’s  and 
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Inter-preds 

Intra-preds 

Reachable  states 

Safety 

Liveness 

Szymanski 

1 

8 

0(214) 

0.1s 

1.82s 

Bakery 

3 

5 

0(2146) 

68.55s 

755.0s 

Figure  4.3:  Running  Times 


the  Bakery  protocol  using  counter  abstraction,  but  they  manually  introduce  new  auxiliary 
variables.  Lahiri  and  Bryant  [53]  verified  the  Bakery  protocol  but  not  Szymanski’s  proto¬ 
col.  Pnueli  et  al.  [64]  have  verified  a  modified  version  of  the  Bakery  protocol  in  which  the 
unbounded  ticket  variable  is  replaced  by  a  bounded  variable.  The  method  described  in  [6] 
can  handle  Szymanski’s  protocol  but  not  the  Bakery  protocol  because  it  has  unbounded 
integer  variables.  A  possible  exception  is  regular  model  checking,  but  this  method  is  very 
different  from  ours  and  encoding  protocols  as  regular  languages  is  a  complex  and  error 
prone  process. 

We  used  the  Cadence  SMV  model  checker  to  verify  the  finite  abstract  model.  The 
model  checking  times  are  shown  in  Figure  4.3.  The  abstraction  time  is  negligible,  less 
than  0.1s.  Figure  4.3  also  shows  the  number  of  predicates  and  the  size  of  the  reachable 
state  space  as  reported  by  SMV.  All  experiments  were  run  on  a  2.4  GHz  Pentium  machine 
with  512  MB  main  memory. 


4.7  Protocols  and  Specifications 


The  details  of  the  two  protocols  that  we  verified  are  given  below. 
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F  =  {pc},  pc  G  {0, 1,  2,  3, 4,  5,  6,  7} 


pc  =  0  :  goto  pc  =  1 

pc  =  1  :  if  Votr  ^  slf.pc[otr]  e  {0, 1,  2, 4}  then  goto  pc  =  2 
else  goto  pc  =  1 

pc  =  2  :  goto  pc  =  3 

pc  =  3  :  if  Votr  7^  slf.pc[otr]  ^1,2  then  goto  pc  =  5 
else  goto  pc  =  4 

pc  =  4  :  if  Votr  7^  slf.pc[otr]  ^  {5,  6,  7}  then  goto  pc  =  4 
else  goto  pc  =  5 

pc  =  5  :  if  Votr  7^  slf.pc[otr]  ^  {2,  3, 4}  then  goto  pc  =  6 
else  goto  pc  =  5 

pc  =  6  :  if  Votr  >  slf.pc[otr]  e  {0, 1, 2}  then  goto  pc  =  7 
else  goto  pc  =  6 

pc  =  7  :  goto  pc  =  0 

Figure  4.4:  Szymanski’s  Mutual  Exclusion  Protocol 
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Szymanski’s  mutual  exclusion  protocols  written  in  our  specification  language  is  shown  in 
Figure  4.4.  This  protocol  has  been  taken  from  [66].  The  protocol  presented  there  has  wait 
statements  that,  under  the  atomicity  assumption,  can  be  modeled  by  guarded  statements. 
The  transition 

pc  =  0  :  goto  pc  =  1 

is  syntactic  sugar  for  the  more  complicated  but  equivalent  guarded  statement 

pc  =  0  :  if  Votr  ^  slf.  true  then  goto  pc  =  1  else  goto  pc  =  1. 

The  property  that  we  verified  for  Szymanski  is 

\/x  ^  y.  AG  .-i [pc[x]  =  7  A  pc[y\  =  7) 
and  the  liveness  property  that  we  verified  is 

\/x.  AG  ,(pc[x]  =  1  — ■>  F  pc[x]  =  7). 

Note  that  pc  =  7  corresponds  to  the  critical  state  and  pc  =  1  corresponds  to  the  trying  state. 
The  only  inter-predicate  is  x  <  y,  were  x,  y  are  index  variables.  As  mentioned  previously, 
the  inter-predicates  and  the  control  assignments  of  the  form  pc  [a;]  =  L  constitute  all  the 
predicates  that  occur  in  the  protocol  text. 

Lamport’s  bakery  algorithm  is  shown  in  Figure  4.5.  The  update  transition 

pc  =  2  A  ch  =  0  :  update  t  :=  0  then  goto  pc  =  0  A  ch  =  0 

is  syntactic  sugar  for 

pc  =  2  A  ch  =  0  :  for  all  otr  ^  slf.  (if  true  then  t  :=  0)  goto  pc  =  0  A  ch  =  0. 
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Note  that  here  we  have  two  finite  variables  pc  and  ch  which  together  determine  the 
control  location.  In  Section  4.2  we  have  argued  that  without  loss  of  generality  we  can 
have  only  one  finite  variable  pc.  In  fact,  we  can  easily  write  the  Bakery  protocol  using 
just  one  finite  variable  pc  with  domain  {0, 1,  2}  x  {0, 1}.  Our  implementation  allows  a 
protocol  to  have  multiple  finite  variables.  Thus,  we  did  not  have  to  rewrite  the  Bakery 
protocol  before  verifying  it. 

The  variable  ch  indicates  whether  a  process  is  updating  its  ticket  variable  t  or  not. 
A  process  updates  its  t  value  by  choosing  the  maximum  among  all  other  t  values  and 
incrementing  it  by  1.  In  Lamport’s  original  paper  [54],  a  process  i  does  the  following 
check  before  entering  the  critical  section: 

for  ally  G  [l..iV] 

L2  :  if  ch[j]  ^  0  goto  L2  else  goto  L3 

L3  :  if  t\j]  >  0  A  ((t [otr] ,  otr)  -<  ( t ,  slf ))  then  goto  L3  else  goto  crit 
crit 

Here  (f[otr],otr)  -<  (t,  slf))  stands  for  t [otr]  <  t  V  (t [otr]  =  t  A  otr  <  slf).  Following 
the  atomicity  assumption  discussed  in  Section  4.2,  we  model  the  for  loop  in  the  original 
Bakery  algorithm  as  a  guarded  transition: 


pc  —  1  A  ch  —  0  :  if  Votr  ^  slf .c/^ [otr]  =  0  A  ^  (t [otr]  >  0  A  ((t [otr],  otr)  -<  (t,  slf))) 
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F  =  {pc,  ch },  pc  G  {0, 1,  2},  ch  G  {0, 1} 


pc  —  0  A  ch  —  0  :  goto  pc  =  0  A  ch  =  1 

pc  —  0  A  ch  —  1  :  for  all  (otr  ^  slf).  if  (f  <  t [otr] )  then  t  t[otr]  +  1 

goto  pc  =  1  A  ch  =  0 

pc  =  lAc/r  =  0  :  if  Votr  ^  slf.c/? [otr]  =  0  A— >(t [otr]  >  0 A ( (t [otr] ,  otr)  -A  (t,  slf))) 
then  goto  pc  =  2  A  ch  =  0 
else  goto  pc  =  1  A  ch  =  0 

pc  —  2  /\  ch  —  0  :  update  t  :=  0  goto  pc  =  0  A  ch  —  0 

Figure  4.5:  Lamport’s  Bakery  Algorithm 
The  safety  property  that  we  verified  is 

Vx  ^  y.  AG  ,-<((pc[x\  =  2  A  ch[x]  =  0)  A  ( pc[y ]  =  2  A  ch[y\  =  0)) 
and  the  liveness  property  that  we  verified  is 

Wx.  AG  .((pc [a;]  =  0  A  ch[x]  —  1)  — >  F  ( pc[x ]  =  2  A  ch[x]  =  0)). 

Note  that  pc  =  2  A  ch  =  0  corresponds  to  the  critical  state,  and  pc  =  0  A  ch  =  0 
corresponds  to  the  trying  state.  The  inter-predicates  that  we  used  are  x  <  y,t(x)  <  t(y), 
t(x)  =  t(y),  that  is,  all  predicates  appearing  in  the  protocol  code  that  compare  variables 
of  two  different  processes. 
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Chapter  5 


Removing  the  Atomicity  Assumption  for 
Mutex  Protocols 


5.1  Introduction 


In  Chapter  4,  we  showed  how  environment  abstraction  can  be  applied  to  verify  mu¬ 
tual  exclusion  protocols,  like  the  Bakery  protocol  and  Szymanski’s  protocol,  completely 
automatically.  But,  the  verification  was  carried  out  under  the  atomicity  assumption.  The 
atomicity  assumption,  in  essence,  says  that  any  process  in  a  distributed  system  consisting 
of  a  collection  of  processes  can  know  the  state  of  all  the  other  processes  instantaneously. 
As  we  will  see  in  Section  5.3,  this  assumption  is  quite  restrictive.  In  this  chapter,  we 
will  show  how  this  assumption  can  be  removed  with  the  help  of  non-interfering  monitor 
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processes  and  thus  verify  mutual  exclusion  protocols  in  their  full  generality. 

All  the  previous  model  checking  based  methods  for  parameterized  verification  have  as¬ 
sumed  atomicity  to  some  extent.  Counter  abstraction  [66]  makes  use  of  this  assumption  as 
does  the  work  on  Invisible  Invariants  [3;  41;  42;  64].  Removing  the  atomicity  assumption 
in  the  latter  method  is  theoretically  possible  but  the  reported  experiments  have  made  use  of 
the  atomicity  assumption.  The  Indexed  Predicates  method  [52;  53]  too  makes  partial  use 
of  atomicity  -  the  update  transition  appearing  in  the  bakery  protocol  is  assumed  to  happen 
atomically.  As  with  the  Invisible  Invariants  method,  removing  the  atomicity  assumption  is 
theoretically  possible  in  the  Indexed  Predicates  method,  but  the  cost  of  verification  is  prob¬ 
ably  high.  The  Inductive  Method,  presented  in  [62],  is  an  exception  to  this  trend.  It  has 
been  applied  to  verify  both  safety  and  liveness  of  the  Bakery  algorithm  without  assuming 
atomicity.  This  approach  however  is  not  automatic  as  the  user  is  required  to  provide  lem¬ 
mas  and  theorems  to  prove  the  properties  under  consideration.  In  contrast,  our  approach 
is  a  fully  automatic  procedure. 

The  outline  for  the  rest  of  the  chapter  is  as  follows.  In  the  next  section,  we  will  present 
the  formal  system  model.  In  section  5.3,  we  will  show,  with  the  help  of  an  example,  why 
the  atomicity  assumption  significantly  reduces  the  complexity  of  a  protocol.  We  will  then 
discuss  how  monitors  can  be  used  to  remove  the  assumption  and  show  how  to  perform  the 
abstraction  in  the  presence  of  these  monitor  processes.  In  the  last  section,  we  will  present 
experimental  results  to  illustrate  our  method. 
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5.2  Modeling  Mutual  Exclusion  Protocols  without  Atom¬ 


icity  Assumption 

As  before,  we  consider  a  parameterized  system  V(K)  with  K  identical  processes  running 
asynchronously  and  communicating  via  shared  variables.  The  state  variables  are  exactly 
the  same  as  in  the  model  considered  in  Section  4.2.  While  we  used  only  two  transition 
constructs  in  the  previous  chapter,  we  will  need  three  different  transition  constructs  to 
describe  mutual  exclusion  protocols  in  their  full  generality.  We  use  guarded  transitions 
and  wait  transitions  for  describing  transitions  involving  only  finite  control,  and  the  more 
complicated  update  transitions  for  transitions  that  modify  data  variables.  Though  guarded 
and  update  transitions  are  syntactically  similar  to  their  counterparts  in  Section  4.2,  their 
semantics  are  quite  different.  The  wait  transition,  as  the  name  indicates,  is  used  to  model 
processes  waiting  for  some  global  condition  to  happen  before  moving.  The  sections  below 
describe  the  transitions  in  detail. 

Guarded  Transitions 

A  guarded  transition  has  the  form 


pc  =  Li  :  if  Votr  ^  slf.t?(slf.  otr)  then  goto  pc  =  L2  else  goto  pc  =  L3 
or  shorter 

L\  :  if  Votr  ^  slf.t?(slf.  otr)  then  goto  L2  else  goto  L3 
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Obligations  :=  {1, A'}  \  {slf } 

Loop  Forever  { 

1.  Pick  otr  e  Obligations 

2.  If  Q (slf,  otr)  then  Obligations  :=  Obligations\ {otr}  else  Exit  Loop 
with  false 

3.  If  Obligations  is  empty  Exit  Loop  with  true  } 

Figure  5.1:  Evaluation  of  a  Guard 

where  A1;  L2,  and  L3  are  control  locations.  In  the  guard  Votr  ^  slf (slf,  otr),  the  variable 
otr  ranges  over  the  process  ids  of  all  other  processes.  The  condition  Q (slf.  otr)  is  any 
formula  involving  the  data  variables  of  processes  slf,  otr  and  the  pc  variable  of  otr.  The 
semantics  of  a  guarded  transition  is  as  follows.  A  process  slf  executing  the  transition  first 
evaluates  the  guard  Votr  ^  slf. Q (slf,  otr)  according  to  the  pseudocode  shown  in  Figure  5.1. 
In  executing  the  loop,  each  line  in  the  code  is  executed  atomically.  This  is  not  a  restricting 
assumption  because  each  line  is  an  internal  action  of  a  process. 

The  then  branch  is  taken  if  the  loop  is  exited  with  value  true  and  pc  is  set  to  L2. 
Otherwise,  the  else  branch  is  taken  and  pc  is  set  to  L3. 


Wait  Transitions 


A  wait  transition  has  the  form 
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Obligations  :=  {1, K }  \  {slf} 

Loop  Forever { 

1.  Pick  otr  e  Obligations 

2.  If  C?(slf.  otr)  then  Obligations  :=  Obligations  \  {otr} 

3.  If  Obligations  is  empty  Exit  Loop  } 

Figure  5.2:  Evaluation  of  a  Wait  condition 


pc  =  Li  :  wait  till  Votr  ^  slf.f/(slf.  otr)  then  goto  pc  =  L2 

or  shorter 

L\  :  wait  till  Votr  ^  slf.t/(slf.  otr)  then  goto  L2 

where  L i,  L2  are  control  locations.  A  process  slf  executing  the  transition  first  evaluates  the 
guard  Votr  ^  slf. Q (slf.  otr)  according  to  the  loop  shown  in  Figure  5.2.  As  with  guarded 
transitions,  each  line  of  the  pseudocode  is  executed  atomically. 

Note  that  unlike  the  loop  for  a  guarded  transition,  the  loop  for  a  wait  transition  cannot 
be  exited  until  the  set  Obligations  is  empty.  Once  the  loop  is  exited  the  process  transitions 
to  new  control  location  L2.  Wait  transitions  are  found  often  in  protocols.  This  construct 
was  not  present  in  Chapter  4  because,  under  the  atomicity  assumption,  the  wait  transition 

Li  :  wait  till  Votr  ^  slf.£(slf.  otr)  then  goto  L2 

is  equivalent  to  the  guarded  transition 

Li  :  if  Votr  ^  slf. Q (slf.  otr)  then  goto  L2  else  goto  Li 
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Update  Transitions 


Recall  that  update  transitions  are  needed  to  describe  protocols  such  as  the  Bakery  algo¬ 
rithm  where  a  process  computes  a  data  value  depending  on  all  values  that  it  can  read  from 
other  processes.  Update  transitions  are  syntactically  of  the  form 


pc  =  Li  :  for  all  otr  ^  slf  if  T (slf.  otr)  then  Uk  :  =  *3>(otr) 

goto  pc  =  L-2 


or  shorter 


L i  :  for  all  otr  ^  slf  if  T(slf,  otr)  then  Uk  $(otr) 

goto  L2 


where  Li  and  L2  are  control  locations,  and  T (slf.  otr)  is  a  condition  involving  data  vari¬ 
ables  of  processes  slf  and  otr.  The  semantics  of  the  update  transition  is  best  understood  in 
an  operational  manner.  A  process  slf  executing  the  update  transition  first  executes  the  loop 
shown  in  Figure  5.3.  Each  line  in  the  pseudocode  is  executed  atomically. 

Once  the  loop  is  exited,  the  process  transitions  to  control  location  L2.  In  control  loca¬ 
tion  Li,  the  process  scans  over  all  the  other  processes  (in  an  arbitrary  nondeterministically 
chosen  order),  and,  for  each  process  otr,  checks  if  the  formula  T (slf.  otr)  is  true.  In  this 
case,  the  process  changes  the  value  of  its  data  variable  uk  according  to  uk  :=  <3>(otr), 
where  <!> (otr)  is  an  expression  involving  variables  of  process  otr.  Thus,  the  variable  uk  can 
be  reassigned  multiple  times  within  a  transition. 

Note  that  in  the  three  loops  above,  process  otr  is  chosen  non-deterministically  from 
the  set  Obligations.  In  real  implementations,  processes  are  usually  evaluated  in  a  fixed 
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Obligations  {1, K}  \  {slf} 

Loop  Forever  { 

1.  Pick  otr  e  Obligations 

2.  If  T (slf,  otr)  then  uk[ slf]  :=  <3>(otr) 

Obligations  :=  Obligations  \  {otr} 

3.  If  Obligations  is  empty  Exit  Loop  } 

Figure  5.3:  Evaluation  of  an  Update 

deterministic  order.  Since  our  semantics  allows  processes  to  be  checked  in  any  order, 
the  protocols  described  in  our  language  contain  more  behaviors  than  the  actual  imple¬ 
mentations.  Thus,  correctness  (involving  ACTL*  properties)  of  a  protocol  written  in  our 
language  implies  the  correctness  of  the  implementation  as  well. 

Remark  13.  In  our  system  model,  we  do  not  consider  how  the  loops  described  above 
are  actually  implemented.  Clearly,  implementing  these  loops  will  require  additional  state 
variables.  We  will  treat  such  variables  as  invisible  variables. 


5.3  Atomicity  Assumption 

In  this  section,  we  discuss,  with  the  help  of  a  running  example,  how  removing  the  atomic¬ 
ity  assumption  makes  a  protocol  considerably  more  complex.  Although  the  atomicity  as¬ 
sumption  simplifies  a  protocol  considerably,  powerful  machinery  is  still  required  to  prove 
protocols  correct  automatically. 
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Consider  the  following  simple  protocol  in  which  each  process  has  just  one  variable  pc. 


init: 

pc  =  1  : 

goto  pc  =  2 

try: 

pc  =  2  : 

if  Votr  7^  slf.pcfotr]  ^  3  then  goto  pc  =  3  else  goto  pc  =  1 

crit’: 

pc  =  3  : 

goto  pc  =  1; 

The  state  of  each  process  is  given  by  the  valuation  of  its  pc  variable.  If  we  assume  that 
the  transitions  are  all  atomic,  it  is  easy  to  see  that  this  protocol  ensures  mutual  exclusion. 
This  is  because  the  guard  condition  =  Votr  ^  slf .Q (otr,  slf)  where  Q (otr,  slf )  =  pc[otr]  ^ 
3  evaluates  to  true  only  when  no  process  is  in  state  pc  =  3.  While  this  simple  protocol  can 
ensure  mutual  exclusion  under  the  atomicity  assumption,  it  cannot  do  so  under  real  life 
conditions,  as  we  describe  below. 

Consider  the  concrete  system  P(3)  with  three  processes  P(  1),  P( 2),  and  P( 3).  Fig¬ 
ure  5.4  shows  a  possible  execution  sequence.  Note  that,  in  giving  this  sequence,  we  assume 
we  have  knowledge  of  the  “insides”  of  a  process:  for  example,  steps  like  “Q  true  of  2”  are 
not  visible.  The  only  things  visible  are  the  pc  and  the  data  variables  of  a  process. 


The  local  states  for  each  of  the  three  processes  are  shown,  and  the  executing  process 
at  each  step  is  indicated  by  an  arrow  (<— ).  The  obsen’ation  step  LQ  true  of  2’  appearing 
under  the  column  for  P(l)  denotes  the  step  in  which  process  P(l)  evaluates  the  guard 
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Process 


Initial  States 


Figure  5.4: 


P(l)  P(2)  P(3) 


pc=  1 

pc=  1 

I 

II 

o 

Q. 

idle 

idle 

I 

<N 

II 

O 

Q. 

Q  true  of  2  * — 

idle 

idle 

Q  true  of  1 

Q  true  of  3  * — 

idle 

idle 

Q  true  of  3 

pc=  3  <— 

idle 

idle 

pc=  3 

pc=l 

idle 

idle 

idle 

idle 

idle 

idle 

idle 

idle 


A  possible  execution  trace  of  the  system  with  three  processes. 
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condition  Q  for  process  P( 2)  and  concludes  that  it  is  satisfied.  Observe  that  in  the  last 
state  both  P(  1)  and  P( 2)  are  in  state  pc  =  3,  violating  mutual  exclusion.  Consider  a  more 
complicated  execution  sequence,  shown  in  Figure  5.5 


Process 


Local  States 


P(l) 


pc=  1 
pc=  2 
pc=  2 
pc=  2 
pc=  2 


Q  true  of  3 


pc=  2 

Q  true  of  2 


pc=  2 
pc=  2 
pc=  3 
pc=  3 


P(2)  P(3) 


pc=  1 

pc=l 

pc=  1 

pc=  1 

pc=  1 

I 

<N 

II 

o 

Q. 

pc=  1 

Q  true  of  1 

pc=  1 

Q  true  of  2 

pc=  1 

pc=  2 

pc=  1 

pc=  3  <— 

pc=  1 

pc=  3 

I 

<N 

II 

o 

Q. 

pc=  3 

Q  false  of  3  <■ — 

pc=  3 

<N 

II 

O 

Q. 

pc=  3 

pc=  1 

pc=  3 

Figure  5.5:  A  more  complicated  trace  of  the  system. 


In  this  sequence,  the  actions  are  interleaved  such  that  process  P( 2)  observes  P(3) 
while  P( 3)  is  in  state  pc  =  3.  Thus  the  guard  is  false  for  2.  Process  P(l)  sees  P( 3) 
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when  it  is  in  pc  =  2,  thus  P( 3)  does  not  block  P(  1).  It  is  clear  from  these  two  examples 
that  the  interleaving  of  actions  is  crucial  and  adds  considerable  complexity  to  the  protocol. 
In  fact,  under  the  atomicity  assumption  neither  of  the  traces  shown  above  are  legal  traces. 
In  particular,  the  execution  sequences  where  the  observation  steps  of  different  processes 
are  interleaved  are  excluded  by  the  atomicity  assumption.  It  is  precisely  because  of  such 
execution  sequences  that  designing  a  distributed  mutual  exclusion  protocol  is  challenging. 


5.4  Monitors  for  Handling  Non-atomicity 


Recall  that  each  process  in  our  system  has  one  pc  variable  and  a  collection  of  data  vari¬ 
ables.  While  it  is  clear  that  interleaving  of  observation  steps  add  considerable  complexity 
to  the  protocol,  none  of  the  variables  used  in  our  systems  really  tracks  the  state  of  these 
observations  steps.  For  example,  consider  again  the  sample  trace  shown  in  Figures  5.4. 
Since  the  obserx’ation  steps  are  hidden  to  the  observers  on  the  outside,  the  execution  trace 
seen  from  the  outside  looks  as  shown  in  Figure  5.6. 


The  current  state  of  process  P{i )  gives  us  no  information  about  how  much  of  global 
condition  it  has  finished  evaluating  and  how  much  is  still  left.  For  example,  at  the  state 
marked  idle  under  column  marked  P(  1)  in  the  figure  above,  we  do  not  know  much  of 
the  guard  condition  <£  =  Votr  ^  slf.pcfotr]  ^  3  has  already  been  evaluated  by  process 
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Process 

P(l) 

P(2) 

P(3) 

Initial  States 

pc=  1 

pc=  1 

pc=l 

1 

<N 

II 

o 

Q. 

idle 

idle 

idle 

I 

<N 

II 

O 

Q. 

idle 

pc=  3  <- 

idle 

idle 

idle 

pc=  3  <- 

idle 

Figure  5.6:  Execution  trace  seen  from  the  “outside”. 

P(  1).  Thus,  if  we  consider  only  the  visible  state  of  processes,  comprising  of  pc  and  data 
variables,  we  have  no  way  of  knowing  the  truth  or  falsity  of  global  conditions  1 . 

Fortunately,  even  when  the  observation  steps  are  invisible,  we  can  gather  some  in¬ 
formation  about  the  truth  or  falsity  of  the  guards  by  looking  at  the  state  of  each  process. 
For  this,  we  have  to  consider  the  previous  states,  in  addition  to  the  current  states,  of  the 
processes.  To  this  end,  we  will  define  a  collection  of  monitor  processes  that  track  the  evo¬ 
lution  of  the  local  states  of  the  processes.  These  monitor  processes  are  non  interfering  and 
are  composed  synchronously  with  concrete  systems  V(K).  By  synchronously  composed 
we  mean  the  following:  every  time  a  process  in  V(K)  moves,  all  the  monitor  processes 
run  simultanesouly  and  update  their  variables  based  on  the  current  state  of  the  processes 
in  'P(K).  Crucially,  the  construction  of  the  monitor  processes  is  not  specific  to  any  par¬ 
ticular  protocol.  In  other  words,  for  any  mutual  exclusion  protocol  we  can  automatically 

'Note  that,  if  we  assume  atomicity,  the  truth  or  falsity  of  guards  can  be  known  just  by  observing  the 
current  states  of  all  processes. 
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construct  the  monitor  processes  defined  below. 

For  each  process  P(i)  in  V(K)  we  have  a  monitor  process  Mg(i).  The  monitor  process 
Mg(i)  has  the  following  variables 

•  K  —  1  variables  mg(i,j),j  ^  i  one  for  each  process  P(j),  j  ^  %  with  range 
{clean,  dirty,  idle}.  These  monitor  variables  are  used  to  handle  guarded  transitions. 

•  Another  set  of  K—  1  variables  mu(i,j),j  ^  i  one  for  each  process  P(j),j  ^  i  with 
range  {clean,  dirty,  idle}.  These  variables  are  used  to  handle  update  transitions. 

•  In  addition,  there  is  one  variable  em[i]  with  range  {clean,  dirty,  idle}. 

Monitor  variables  have  value  idle  if  they  are  not  in  use.  Usually,  monitor  variables 
transition  to  value  dirty  from  value  idle.  Typically,  a  monitor  variable  being  dirty  indicates 
that  certain  actions  are  not  possible  (an  exception  to  this  is  the  value  dirty  of  em  variable, 
which  actually  permits  more  behaviors).  After  this  the  monitor  variable  may  transition  to 
value  clean.  This  value  for  a  monitor  variable  usually  indicates  that  the  monitor  variable 
has  seen  enough  history  information  to  allow  all  behaviors.  Sometimes  a  monitor  variable 
can  transition  from  value  idle  to  clean  directly.  Once  a  variable  has  become  clean,  it  will 
stay  clean  until  it  is  reset  to  idle. 

In  the  next  two  subsections  we  will  describe  how  the  monitor  variables  are  updated 
by  the  monitor  processes.  We  will  also  formalize  the  exact  information  that  we  gain  from 
monitor  processes. 
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Monitor  Variables  for  Guarded  Transition 


The  variable  mg(i ,  j )  keeps  track  of  process  j  and  is  updated  as  shown  in  the  Figure  5.7. 

The  value  of  mg(i,  j)  is  computed  as  follows: 

1.  If  process  i  is  not  evaluting  any  guard  mg(i,j)  =  idle. 

2.  If  mg(i,  j)  =  idle  and  process  i  is  evaluating  a  guard  with  condition 
£/(slf,  otr)  and  G(i,j)  is  false  then  mg(i,j)  =  dirty. 

3.  If  process  i  is  evaluting  a  guard  with  condition  Q (slf,  otr)  and  Q ( i ,  j) 
is  true  then  mg(i,j )  =  clean. 

4.  Otherwise  mg(i,j)  retains  its  value 

Figure  5.7:  Update  procedure  for  monitor  variables  pertaining  to  guarded  transitions. 

Intuitively,  the  variable  mg(i,j)  present  in  monitor  Mg(i )  tracks  whether  process  j 
entered  any  state  that  makes  the  guard  condition  G{i,j)  true  while  process  i  is  evaluating 
the  guard  £f(slf.  otr)  =  Votr  ^  slf.£(slf.  otr).  In  such  a  case,  the  monitor  variable  is  clean. 
Otherwise  it  is  dirty.  Informally,  the  variable  mg(i,  j )  being  dirty  means  that  process  j  will 
block  the  guard  (slf  otr)  for  process  i. 

This  code  is  run  by  the  monitor  process  after  each  step  of  the  asynchronous  system 
V(K).  Note  that,  the  monitor  process  does  not  intefere  with  the  execution  of  V(K)  in  any 
way. 

The  variable  em(i)  with  range  {clean,  dirty,  idle}  is  updated  as  shown  in  Figure  5.8. 
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The  value  of  variable  em(i)  is  fixed  as  follows: 

1.  If  process  i  is  not  evaluating  any  guard  then  em  =  idle. 

2.  If  process  i  is  a  evaluating  a  guard  with  condition  Q  (slf .  otr)  and  there 
exists  a  process  j  f  i  such  that  G(i,j)  is  false  then  em  =  dirty. 

3.  If  process  i  is  a  evaluating  a  guard  with  condition  ^7 (slf.  otr),  em  f 
dirty  and  for  all  processes  j  f  i  G(i,j)  is  true  then  em  =  dirty. 

4.  Otherwise  em(i,j)  retains  its  value. 

Figure  5.8:  Procedure  for  updating  monitor  variables  pertaining  to  guarded  transitions. 

Intuitively,  if  any  process  j  f  i  was  in  a  state  that  falsified  the  guard  G(i-.j)  while 
process  i  was  evaluating  it,  then  em(i)  becomes  dirty.  It  stays  dirty  until  it  is  reset  to  idle. 
Against  the  general  trend,  value  of  em  can  go  from  idle  to  clean  to  dirty.  In  fact,  the  value 
dirty  for  em  actually  means  more  behaviors  are  possible. 

Variable  em(i)  tracks  whether  any  process  j  f  i  was  in  a  state  which  makes  G(i-j) 
false  while  P{i )  is  evaluating  G(i,j)-  If  such  a  process  exists,  em(i)  is  set  to  dirty.  If  P{i) 
is  not  evaluating  any  guard,  then  em(i)  is  set  to  the  default  value  clean. 

The  information  given  by  monitor  processes  can  be  used  to  decide  -  approximately- 
the  truth  or  falsity  of  the  guards.  The  following  lemma  formalizes  the  relation  between  the 
monitor  variables  and  guards. 

Lemma  5.4.1.  Let  process  i  in  a  concrete  system  P(K )  be  evaluating  a  guard  with  con¬ 
dition  7  (slf.  otr).  Then  we  have  the  following: 
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•  If  process  i  concludes  that  the  guard  is  true,  then  cdl  monitor  variables  mg(i.j), 
j  i,  must  be  clean. 

•  If  the  process  i  concludes  that  the  guard  is  false,  then  the  variable  em(i )  is  dirty. 

Proof  This  lemma  follows  trivially  from  the  way  we  defined  the  monitor  variables  mg(i,  j), 
j  i  and  em(i).  □ 

Monitors  Variables  for  Update  Transitions 

Consider  an  update  transition 


Li  :  for  all  otr  f  slf  if  T (slf.  otr)  then  Uk  :  =  <l>(otr) 

goto  L2 

This  transition  updates  the  variable  Uk  of  the  executing  process  and,  thus,  affects  the 
mutual  relationships  between  the  Uk  variables  of  the  different  processes.  To  predict  what 
possible  relations  (more  precisely  predicates)  hold  between  Uk[i]  and  Uk[j\  after  process 
i  executes  the  above  transition,  we  described  an  automatic  procedure  in  Section  4.5.  The 
fixpoint  based  computation  presented  in  Section  4.5,  assumes  atomicity,  that  is,  when 
process  i  is  performing  an  update  all  the  other  processes  stay  fixed.  Under  this  assumption, 
we  can  find  a  set  F(uk[i\,uk\j])  of  all  predicates  of  interest  that  can  hold  between  uk[i] 
and  uk  [j]  after  the  update. 

But,  without  the  atomicity  assumption,  the  fixpoint  computation  is  no  longer  valid. 
More  precisely,  if  process  j  also  performs  an  update  operation  on  variable  uk  while  process 
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i  is  doing  the  same,  then  we  cannot  use  the  fixed  point  computation  to  predict  which 
relationships  hold  between  uk[i]  and  uk[j]  after  the  update  operation.  In  this  case,  we 
just  say  that  the  set  of  all  possible  relations  between  uk[i],uk\j]  is  simply  uk\j]), 

where  F{uk[i\,uk\j])  is  the  set  of  all  possible  predicates  of  interest  (usually  syntactically 
picked  from  the  protocol  code). 

Thus,  if  we  knew  that  two  processes  were  not  updating  the  same  variable  t  simul¬ 
taneously,  then  we  can  better  predict  the  set  of  possible  relations  after  the  update  using 
the  fixpoint  computation.  The  K  —  1  variables  mu(i,  1), . . . ,  mu(i,  i  —  1  ),mu(i,i  + 
1), . . . ,  mu{i ,  K)  with  range  (clean,  dirty,  idle}  try  to  track  precisely  this  information:  the 
variable  mu(i,j )  tells  us  whether  process  j  was  updating  the  same  data  variable  at  the 
same  time  as  process  i.  The  value  of  the  variable  mu(i,j)  ,  j  ^  i  is  computed  as  shown 
in  Figure  5.9. 

Intuitively,  mu(i,j )  being  clean  indicates  that,  at  some  point  when  process  i  was  up¬ 
dating  its  variable  t,  process  j  was  also  updating  the  same  variable  t.  We  can  use  the 
information  contained  in  the  monitor  processes  to  abstract  the  concrete  behaviors  as  fol¬ 
lows: 


•  If  there  is  a  process  j  such  that  mu(i,j)  is  clean  then  the  valuation  of  a  predicate 
involving  uk{j]  and  uk[i]  could  be  anything  as  uk[j]  might  have  changed  while  uk['i] 
was  being  updated. 

•  If  process  j  is  such  that  mu(i,j )  is  dirty  then  we  know  that  uk[j]  could  not  have 
changed  while  i  was  executing  the  update  transition.  It  is  possible  to  figure  out  the 
possible  relationships,  after  the  update,  between  Uk[i]  and  uk[j]  as  described  above. 
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The  value  of  the  variable  mu(i,  j )  is  computed  as  follows 

•  If  process  i  is  not  evaluating  any  update  transiton,  then  mu(i,j )  = 
idle. 

•  If  mu(i,j )  =  idle,  process  i  is  evaluating  an  update  transition  in¬ 
volving  variable  t,  and  process  j  is  not  doing  any  update  involving  t, 
then  mu(i,j)  =  dirty. 

•  If  both  processes  i  and  j  are  doing  update  transitions  involving  the 
same  unbounded  variable  t,  then  mu(i,j )  =  clean. 

•  Otherwise  mu(i,j )  retains  its  value. 

Figure  5.9:  Procedure  for  updating  monitor  variables  pertaining  to  update  transitions. 
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The  following  lemma  formalizes  the  relationship  between  the  monitor  variables  and 
the  update  transitions. 

Lemma  5.4.2.  Suppose  process  i  is  updating  variable  t  in  an  update  transition  with  the 
update  expression  T(slf,  otr).  Let  F(uk[i],  uk[j])  be  thefixpoint  of  predicates  as  computed 
in  Section  4.5.  Ifmu(i,j )  =  dirty,  then  the  set  of  predicates  that  hold  between  ///,.[/’]  and 
uk[j]  after  process  i  has  finished  the  update  transition  is  a  subset  of  F(uk[i],  ukf]\). 

Proof.  The  proof  follows  from  the  fact  that  mu(i,j )  is  dirty  only  if  process  j  was  not 
updating  its  uk[j\  variable  while  process  i  was  updating  its  uk[i]  variable.  Thus,  by  the  way 
we  compute  the  fixpoint  F(uk[i].  uk{]\),  it  contains  all  the  possible  relationships  between 
uk[i]  and  uk[j]  after  the  update  by  process  i.  □ 

Thus,  our  lack  of  information  about  the  invisible/hidden  steps  (used  in  evaluating 
guards  and  updates)  can  be  overcome  by  making  use  of  synchronously  composed  non 
interfering  monitors  and  we  can  build  a  sound  abstraction  of  the  actual  behaviors. 

Remark  14.  Note  that  a  process  can  either  execute  a  guarded  transition  or  an  update  tran¬ 
sition,  but  not  both  at  the  same  time.  Thus,  instead  of  having  two  sets  of  variables,  namely 
mg(i,j),j  i  and  mu(i,j),j  i,  we  can  just  have  one  set  of  variables  m(i,j),j  f  i 
with  range  (clean,  dirty}. 

From  now  on,  each  monitor  process  Mg(i)  will  have  variables  {rrifi.  j )  |  j  f  i]  and  the 
variable  em(i). 
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5.4.1  Abstracting  the  Monitor  Variables 


As  in  Chapter  4,  we  start  with  descriptions  of  A  (a;)  having  the  format 

pc[x]  —  i  A  ±£i(x)  A  ±£2(x)  A  •  •  •  A  ±£t(x),  where  i  G  [1..S]. 

where  the  environment  prediates  £{(x)  are  constructed  as  before.  But,  the  abstract  model 
constructed  using  descriptions  A(x)  given  above  will  not  have  enough  detail  to  verify  a 
protocol  without  the  atomicity  assumption.  Therefore,  we  augment  our  abstract  states  so 
that,  in  addition  to  the  state  of  the  reference  process  and  its  environment,  they  also  contain 
the  history  information  contained  in  the  monitor  processes.  Our  augmented  abstract  states 
will  be  of  the  form 


(pc,  ex, ,  er,  ti, . . . ,  tr,  b\, . . . ,  br,  te) 

where  the  variables  ti, ...  ,tT  and  te  (called  trackers )  abstract  the  monitor  variables 
of  the  reference  process,  bi,...,bT  (called  backers)  abstract  the  monitor  variables  of  the 
environment  processes.  We  now  describe  how  to  abstract  the  different  monitor  variables. 

Abstracting  Trackers 

Consider  first  the  reference  process  x.  Apart  from  the  reference  process,  no  other  process 
is  individually  identifiable  in  the  abstract  state.  Corresponding  to  each  environment  condi¬ 
tion  £i,  we  have  an  abstract  variable  t,  with  range  (clean,  dirty,  both}  which  abstracts  the 
information  present  in  the  monitors.  The  value  of  ti  is  computed  as  follows: 
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•  If  for  all  the  processes  y  satisfying  environment  predicate  Ei(x,y )  the  variable 
m(x,y )  =  clean,  thenfj  =  clean. 

•  If  for  all  the  processes  y  satisfying  environment  predicate  Ei(x,y )  the  variable 
m(x,  y)  =  dirty,  then  tt  =  dirty. 

•  Otherwise  tt  =  both. 

Given  a  concrete  state  s  of  a  system  V(K)  with  reference  process  x  and  an  environment 
Si,  the  value  of  tracker  ti  is  uniquely  determined.  We  denote  the  function  from  (s,  x,  i)  to 
ti  by  T1 .  This  function  will  be  used  later  on. 

In  addition,  we  have  another  variable  te  that  abstracts  the  monitor  variable  ern  (x).  The 
value  of  te  is  exactly  the  same  as  value  of  em(x). 

Abstracting  Backers 

Trackers  maintain  history  information  that  is  relevant  for  the  reference  process.  We  also 
need  to  abstract  the  information  present  in  the  monitors  for  processes  other  than  the  ref¬ 
erence  process  x.  In  particular,  for  each  environment  process  y,  we  are  interested  in  the 
monitor  variable  m(y,  x).  As  noted  earlier,  environment  processes  are  grouped  according 
to  the  environment  condition  they  satisfy.  For  an  environment  Si,  we  maintain  a  variable 
bci  that  combines  the  m(y,  x)  variables  of  all  processes  y  in  the  environment  £t  .  The  value 
of  bci  is  computed  as  follows: 

•  If  for  all  processes  y  satisfying  Et(x,  y)  we  have  m(y ,  x)  =  clean,  then  bet  =  clean. 
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•  If  for  all  processes  y  satisfying  Ei(x,  y)  we  have  m(y,  x )  =  dirty,  then  bc.t  =  dirty. 

•  Otherwise  bc,i  =  both. 

Given  a  concrete  state  s  of  a  system  V(K)  with  reference  process  x  and  an  environment 
Si,  the  value  of  be,  is  uniquely  determined.  We  can  denote  the  function  from  (s,  x,  i)  to  bet 
by  Tb .  This  function  will  be  used  later  on. 

We  will  now  define  the  abstraction  mapping  from  augmented  concrete  states  to  aug¬ 
mented  abstract  states. 

Definition  5.4.3  (Abstraction  Mapping).  Let  P(K),  K  >  1,  be  a  concrete  system  and 
p  G  [1  ..K]  be  a  process.  The  abstraction  mapping  ap  induced  by  p  maps  a  global  state  s 
of  V(K)  to  an  abstract  state  (pc,  e1} . . . ,  eT,  h, . . . ,  tT,  biP, . . ,  bT,  te)  where 

•  pc  =  the  value  of  pc \p\  in  state  s  and  for  all  e3,  we  have  e3  —  I  <=X  s  ^  Sj(p ). 

•  For  all  j  we  have  tj  =  T1  (s,  p,  j),  and  for  all  j,  we  have  b3  =  Pb(s,  p,  j ) 

The  corresponding  augmented  abstract  model  VA  is  defined  as  in  Section  2.5.2.  The 
set  of  labels  is  the  same  as  the  labels  used  in  Section  4.2.  From  the  coverage  and  congru¬ 
ence  properties  of  the  original  abstract  descriptions  we  can  conclude  that  the  same  prop¬ 
erties  hold  for  the  augmented  abstract  descriptions  as  well.  Thus,  the  following  corollary 
follows  from  Theorem  2.2.4. 

Corollary  5  (Soundness  of  Augmented  Abstraction).  Let  V(N)  be  a  parameterized 
mutual  exclusion  system,  'P.M(N)  be  an  augmentation  of  'P(N)  with  monitor  processes 
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as  described  above,  and  VM.A  be  its  augmented  abstraction.  For  an  indexed  property 
\/x.$(x),  where  <F(a;)  is  a  control  condition  we  have 


VMa  h  Hx)  =*►  VK.VM(K)  |=  Vx.$(x)  =»  VK.V(K)  {=  Vx.$(x) 


5.5  Computing  the  Abstract  Model 


As  in  the  atomicity  case,  we  consider  the  following  four  cases  for  computing  an  over¬ 
approximation  of  a  transition  statement: 


Active  process  is  . . . 

guarded  transition 

update  transition 

. . .  reference  process 

Case  1 

Case  2 

. . .  environment  process 

Case  3 

Case  4 

Before  we  begin,  we  recall  the  notation  introduced  earlier  in  Section  4.5.  The  envi¬ 
ronment  condition  Efx,y )  =  y  f  x  A  Rj(x,y )  A  pc [y]  =  L  is  denoted  by  E^^(x,y). 
The  corresponding  environment  predicate  is  referred  to  as  E^j^ix)  and  the  corresponding 
abstract  variable  is  e^yL).  The  set  of  all  environment  conditions  E(j^{x,  y )  is  referred  to 
as  El. 


5.5.1  Case  1:  Guarded  Transition  for  Reference  Process 

Let  us  now  turn  to  Case  1  and  consider  the  guarded  transition  tG: 

Li  :  if  Votr  f  slf.£(slf,  otr)  then  goto  L2  else  goto  L3 
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Suppose  at  least  one  of  the  trackers  U ,  i  €  [1..T]  is  not  clean.  Then  the  reference 
process  cannot  conclude  the  guard  is  true.  If  all  the  trackers  are  clean,  then  we  may 
conclude  that  the  guard  is  true  or  false.  Once  reference  process  x  ends  up  in  a  new  control 
location,  we  have  to  appropriately  assign  new  values  to  the  trackers  and  the  backers.  To 
do  this  we  need  the  following  two  definitions.  The  first  definition  is  exactly  the  same  as 
the  one  in  Chapter  4,  but  we  repeat  it  for  the  sake  of  completeness. 

Definition  5.5.1  (Blocking  Set  for  Reference  Process).  Let  Sf  =  Votr  ^  slf.ClsIf.  otr)  be 
a  guard.  We  say  that  an  environment  condition  Efx,  y )  blocks  the  guard  if  Et{x,  y )  => 
~>G(x,  y).  The  set  Bx\ Sf)  of  all  indices  i  such  that  Efx,  y)  blocks  is  called  the  blocking 
set  of  the  reference  process  for  guard 

Note  that  either  Efx,  y)  =>  -i Q[x ,  y)  or  Efx,  y)  =>-  G(x ,  y)  holds  for  every  environ¬ 
ment  Efx,  y). 

Each  environment  uniquely  determines  the  control  location  of  the  processes  satis¬ 
fying  it.  We  will  assume,  for  simplicity,  that  there  is  only  one  transition  starting  at  each 
control  location 2.  Thus,  each  environment  £%  has  an  unique  guard  or  update  expression  as¬ 
sociated  with  it.  The  following  notion  of  dependent  environments  for  guarded  transitions 
is  similar  to  the  blocking  set  for  the  reference  process. 

Definition  5.5.2  (Dependent  Set  for  Guards).  Let  pc  =  L  be  a  control  location  of  the 
reference  process.  The  guard  dependent  set  of  L,  V9(L)  contains  all  those  environments 
whose  associated  guard  =  Votr  f  slf.^7 (slf ,  otr)  are  such  that  Efy,x)  A  G(y,x )  A 
(pc[x]  =  L)  is  satisfiable. 

Extension  to  the  general  case  is  simple. 
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Intuitively,  the  guard  dependent  set  of  a  control  location  pc  =  L  is  the  set  of  all  those 
environments  whose  associated  guards  are  such  that  the  reference  process  x  in  control 
location  pc  =  L  does  not  contradict  the  guards.  Thus,  a  process  y  present  in  any  such 
environment  could  have  seen  the  reference  process  x  satisfy  process  y’s  guard.  We  define 
update  dependent  sets  similarly. 

Definition  5.5.3  (Dependent  Set  for  Updates).  Let  pc  =  L  be  a  control  location  of  the 
reference  process.  The  update  dependent  set  of  L ,  V"(L),  contains  those  environments 
whose  associated  update  expression  updates  the  same  data  variable  as  the  update  transition 
associated  with  L.  If  there  is  no  update  transition  associated  with  pc  =  L  then  the  set  is 
empty. 

We  will  now  explain  how  to  abstract  the  guarded  transition  f  G 

Li  :  if  Votr  ^  slf .d/  (slf ,  otr)  then  goto  L2  else  goto  L3. 

We  will  represent  the  set  of  abstract  transition  arising  from  this  case  by  an  invariant  (be¬ 
tween  current  and  next  states)  If  .  The  invariant,  structured  similar  to  the  one  in  Sec¬ 
tion  4.5,  will  be  presented  in  terms  of  three  conditions  GR1,  GR2,  GR3.  The  abstract 

model  will  have  transition  from  s)  =  (pc,  eu  ..,  eTlt\ _ ,  tT,  bc3, . . . ,  bcT,  te)  to 

s2  =  (pc',  ei, ..,  eT,  t\ . ,  t'T,  bc[, ,  bc'T ,  te1)  if 

GR1.  pc  =  Li,  i.e.,  the  reference  process  is  in  location  L1; 

GR2.  One  of  the  following  two  conditions  holds: 
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•  Then  Branch:  V*).(£j  =  clean)  and  pc'  =  L2,  i.e.,  the  guard  is  true  and  the 
reference  process  moves  to  control  state  L2. 

•  Else  Branch:  =  clean)  V  (Vi.f*  =  clean  Ate  =  dirty)  and  pc'  =  L3, 

i.e.,  the  guard  is  false  and  the  reference  process  moves  to  control  state  L:>.  Note 
that  the  condition  te  =  dirty  indicates  that  at  least  one  tracker  was  dirty  at  some 
point  in  the  past. 

GR3  Assuming  pc'  =  L  where  L  e  {L2l  £3}  the  following  conditions  hold. 

•  If  the  transition  associated  with  control  location  L  is  a  guarded  transition  with 

=  Votr  ^  slf.£f(slf.  otr),  then  the  following  conditions  hold. 

-  If  1  e  BX\Q)  or  e'  =  0  then  t\  =  clean.  Else  t\  =  dirty,  i.e.,  if  £t  is  a  not 
blocking  environment  or  if  the  environment  is  empty  the  corresponding 
tracker  is  clean.  Otherwise,  it  is  set  to  dirty  as  there  is  a  process  in  a 
blocking  environment. 

-  If  i  <G  V9(L)  U  VU(L),  then  bc\  =  clean  else  bc\  =  bci.  i.e.,  if  the 
reference  process  does  not  block  the  guard  associated  with  environment 
Si  or  updates  the  same  variable  as  the  update  transition  associated  with  £% 
then  bci  is  set  to  clean,  otherwise  it  is  set  to  dirty. 

-  If  there  exists  an  i  such  that  t\  =  dirty  then  te  =  dirty,  i.e.,  the  variable  te 
is  dirty  if  at  least  one  of  the  trackers  is  dirty. 

•  If  the  transition  associated  with  control  location  L  is  an  update  transition  then 
the  following  conditions  hold 
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-  If  i  e  VU(L)  and  e'  =  1  then  t[  =  clean.  Else  t\  =  dirty.  That  is,  if 
environment  et  updates  the  same  data  variable  as  the  reference  process  in 
control  location  L,  then  the  tracker  t,  must  be  set  to  clean  otherwise  tt  is 
set  to  dirty.  This  indicates  that  both  the  reference  process  and  a  process  in 
e*  can  change  the  same  data  variables  simultaneously. 

-  If  i  G  Vg(L),  then  bc[  =  clean  else  6c'  =  6q.  That  is,  if  control  location 
L  is  such  that  the  guard  associated  with  er  is  not  blocked  by  the  reference 
process  in  control  location  L,  then  the  backer  bet  is  set  to  clean. 

-  te'  =  clean.  This  is  a  default  value  for  te  as  it  is  not  really  used  for  update 
transitions. 

Similar  to  the  concrete  monitor  variables,  the  value  clean  for  trackers  and  backers  is 
the  most  permissive  -that  is,  if  backers  and  trackers  are  clean,  then  the  possible  set  of 
transitions  is  maximal.  The  value  both  is  slightly  more  restrictive  than  clean:  the  envi¬ 
ronments  corresponding  to  trackers  and  backers  that  are  in  the  both  state  cannot  be  empty. 
The  value  dirty  is  the  most  restrictive.  A  tracker  being  dirty  prevents  the  reference  pro¬ 
cess  from  moving  forward.  Similarly,  a  backer  being  dirty  prevents  the  processes  of  the 
corresponding  environment  from  moving  forward. 

Lemma  5.5.4.  If  states  Si  and  s2  in  a  concrete  system  'P(K),  K  >  1  are  such  that 
ac(si)  =  Si  and  ac(s2)  =  s2  and  there  is  a  transition  from  .S]  to  s2  via  process  c  exe¬ 
cuting  a  guarded  transition  tG  then  Si  and  s2  satisfy  the  transition  invariant  If  . 

Proof  This  follows  simply  from  the  way  we  constructed  the  invariant.  □ 
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Note  that  all  we  have  done  is  to  translate  the  lemmas  listed  in  Section  5.4  in  terms 


of  the  reference  process  and  its  environment.  This  is  precisely  where  the  power  of  this 
approach  comes  from.  Constructing  the  abstract  model  is  theoretically  simple  and  it  is 
easily  extendible  in  case  new  constructs  are  allowed  in  the  concrete  protocols. 

5.5.2  Case  2:  Guarded  Transition  for  Environment  Processes 


Suppose  that  the  guarded  transition  to 

Li  :  if  Votr  ^  slf.£(slf,  otr)  then  goto  L2  else  goto  L3 

is  executed  by  a  concrete  process  y  satisfying  the  environment  condition  E^!Ll)(x,y). 
The  active  process  thus  switches  from  environment  condition  Eul^x,  y)  to  environment 
condition  E(ijL2)(x,  y)  or  E(ijL3)(x,  y).  Note  that  in  a  guarded  transition,  only  the  pc  of  the 
active  process  changes. 

We  denote  the  abstract  transition  corresponding  to  this  case  by  an  invariant  If  (to)-  We 

introduce  an  abstract  transition  from  si  =  (pc,  e±, ..,  ex,  h _ ,  tx,  bci, _ ,  bcx,  te)  to 

s2  =  (pc',  e[, ..,  e'T,  t’x _ ,  t'T,  bc[, . . . ,  bc'T,  te)  if  the  following  conditions  hold.  For 

brevity  we  will  represent  the  environment  condition  by  £x,  £(i,L2)  by  £2,  £{i,L3) 

by  £3- 

GE1.  e i  =  1,  that  is,  there  is  an  environment  process  in  state  control  location  L ,  3. 

3The  requirement  that,  for  each  control  location  L,  there  be  only  one  transition  starting  from  L  is  being 
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GE2  One  of  the  following  two  conditions  holds: 


•  Then  Branch:  bck  €  {clean,  both}  and  e'2  =  1,  i.e.,  the  guard  is  true  and  the 
reference  process  moves  to  control  state  L2.  e\  can  be  0  or  1. 

•  Else  Branch:  e3  =  1,  i.e.,  the  guard  is  false  and  the  environment  process  moves 
to  control  state  L3.  e\  can  be  0  or  1. 

GE3.  pc'  =  pc.  That  is,  the  control  location  of  the  reference  does  not  change. 

GE4.  Let  the  new  control  location  of  the  environment  process  be  L  e  { L2.  L3}.  Denote 
the  environment  E^L\  by  E:j  for  the  sake  of  brevity.  The  following  conditions  must 
hold: 


•  tj  =  oj(t  | ,  tj).  Function  u,  described  below,  takes  the  current  values  of  the 
trackers  t\,  tj  and  returns  the  new  value  for  tr 

•  t\  =  Qt(t  1,6}).  Function  Qt,  described  below,  takes  the  current  value  of  a 
tracker  (or  a  backer)  and  the  next  state  value  of  the  corresponding  environment 
and  returns  the  next  state  value  of  the  tracker  (or  the  backer). 

•  bc\  =  flt(bci,  e}). 

•  If  the  transition  associated  with  L  is  a  guarded  transition  then 

bc'j  =  ilh(V0(L).  be/).  Function  Qb  finds  the  new  value  of  backer  bc2  as  a 
function  of  the  current  value  of  the  backer  bcj  and  the  guard  dependent  set  of 
control  location  L. 

used  here. 
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•  If  the  transition  associated  with  L  is  an  update  transition,  then 


bdj  =  nb{Vu(L),bCj). 


Function  c u(U,  tj )  is  shown  in  tabular  form  in  Figure  5.10 


Function  u>(tj,  tj)  returns  the  new  value  of  t3  given  the  current  values  of  tt 
and  tj. 


tj 

U 

tj  ) 

tj  =  clean 

ti  =  dirty 

t'j  =  both 

tj  =  dirty 

ti  =  dirty 

t'j  =  dirty 

tj  =  clean 

tj  =  clean 

t'j  =  clean 

tj  =  dirty 

tj  =  clean 

t'j  =  both 

tj  =  clean 

tj  =  both 

t'j  =  both 

tj  =  dirty 

tj  =  both 

t'3  =  dirty 

tj  =  both 

- 

t'j  =  clean 

Figure  5.10:  Function  u>. 


Informally,  this  new  value  of  tj  should  reflect  the  collective  status  of  processes  in 
the  environment  6j.  When  a  new  process  moves  into  the  environment  e3,  we  can  figure 
out  the  status  of  this  new  process  by  looking  at  the  tracker  value  associated  with  its  old 
environment.  Depending  on  these  two  values,  the  current  values  of  t3  and  tj,  we  can  figure 
out  the  new  value  of  tj  so  that  it  reflects  the  collective  condition  of  the  processes  in  the 
environment  e3. 

Function  U)  is  shown  in  Figure  5.11.  The  function  code  is  self-explanatory  as  is 
the  function  flb(Set,  bcj)  given  in  Figure  5.5.2 
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Function  f2t(e',  tr)  returns  the  new  value  of  the  tracker  t,  given  the  current 
value  of  the  tracker  and  the  next  value  of  the  corresponding  environment 
bit  et. 

•  If  e\  =  0  then  t\  =  clean 

•  Otherwise 

-  If  ti  =  clean  then  f  =  clean 

-  If  ti  =  dirty  then  t[  =  dirty 

-  If  ti  =  both  then  t  '  e  {clean,  dirty,  both} 

Figure  5.11:  Function  V.t. 

Lemma  5.5.5.  If  states  si  and  s 2  in  a  concrete  system  V(K),  K  >  1  are  such  that 
ac(si)  =  Si  and  ctc(s2)  =  §2 ,  c  E  [1  ..K]  and  there  is  a  transition  from  si  to  S2  via 
process  d  f  c  executing  a  guarded  transition  to,  then  si  and  $2  satisfy  the  transition 
invariant  Iy(ta)- 

Proof.  The  proof  of  this  lemma  follows  directly  from  the  way  we  constructed  Iy(ta)-  □ 

5.5.3  Case  3:  Update  Transition  for  Reference  Process 

Consider  the  case  where  the  reference  process  is  executing  an  update  transition  tjj\ 
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Function  Q/,  takes  set  of  environment  conditions  and  one  backer  as  its  ar¬ 
guments  and  returns  the  new  value  of  the  backer. 

•  If  Ej  e  Set  then  6c'  =  clean 

•  Ej  (fi  Set  then  one  of  the  following  holds: 

-  If  bcj  =  clean  or  bcj  =  both  then  6c'  =  both 

-  If  bcj  =  dirty  then  6c'  =  dirty 

Figure  5.12:  Function  Q;, 


Li  :  for  all  otr  ^  sit  if  T (slf.  otr)  then  uk  :=  <3>(otr) 

goto  L2 

Recall  that  each  process  has  data  variables  ui,...,ud.  We  denote  the  next  state  value 
of  each  variable  urn  by  u'm. 

When  the  reference  process  x  changes  the  value  of  its  data  variables,  the  valuations  of 
the  environment  predicates  S\(x) . . .  £t(x)  will  change.  For  a  process  y  satisfying  envi¬ 
ronment  condition  Ei(x,  y ),  we  need  to  figure  out  the  possible  new  environment  conditions 
Ej  (x,  y  )  that  y  will  satisfy  after  the  reference  process  x  has  executed  the  update  transition. 
Recall  from  Chapter  4  that  the  set  of  possible  new  environment  conditions  for  process  y 
satisfying  the  condition  Et(x,  y)  is  called  the  outset  Oi.  (Technically,  the  outset  is  the  set 
of  the  indices  of  these  environment  conditions.)  For  sake  of  completeness,  we  will  briefly 
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explain  again  how  to  compute  the  outset. 


Case  A. 

The  first  case  we  need  to  consider  is  when  process  y  does  not  update  uk  while  the  reference 
process  is  updating  its  variable.  Denote  by  T(x,  y)  the  update  formula  T {x,  y)  A  u'k[x\  :  = 
4>{y)  V  -i T(x,y)  A  u'k[x]  :=  Uk[x}.  Given  the  update  formula,  we  find  what  possible 
inter-predicates  involving  u'k[x],Uk[y\  can  be  true.  Formally,  the  set  G'1  (uk)  of  these  inter¬ 
predicates  is  given  by  all  formulas  Uk[x\  -<  Uk[y]  where  -<e  {<,>,=}  such  that 

uk[x]  -<  uk[y\  A  T(x,  y)  is  satisfiable. 

The  possible  relationships  between  uk[x]  and  uk[y]  might  change  when  x  repeatedly  up¬ 
dates  its  uk  value  by  looking  at  other  processes.  Suppose  x  looks  at  another  process  z  and 
updates  its  uk[x]  value  again.  We  now  find  the  set  C2{uk )  of  possible  relationships  be¬ 
tween  uk[x]  and  uk[y]  after  the  new  update  involving  process  z  under  the  assumption  that 
a  relation  from  Cl{uk)  holds  before  the  update.  Thus,  the  new  set  C2{uk)  of  relationships 
is  given  by  all  formulas  uk[x]  -<  uk [y]  where  -<e  {<,>,=}  such  that 

u'k[x]  -<  uk[y\  A  T(x,  z)  A  ip(x,  y)  is  satisfiable  and  f>(x,  y)  G  C1^). 

Note  that  Cl{uk )  C  C2{uk)  because  the  definition  of  T(x,  z)  allows  the  possibility  that 
the  value  of  uk[x\  remains  unchanged.  We  similarly  compute  sets  C3(uk),  C4(uk) . . .  until 
a  fixpoint,  C(uk),  is  reached. 

In  the  environment  condition  Efx,y ),  let  9  be  the  (unique)  inter-predicate  that  de¬ 
scribes  the  relation  between  uk[x]  and  uk \y\ .  Consider  the  set  of  environment  conditions 
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Ej(x,y )  that  are  obtained  from  E%(x.  y)  by  replacing  6  with  a  formula  in  the  fixpoint 
C(uk ):  the  indices  of  these  environment  conditions  constitute  the  outset  Oi  of  E^x,  y). 

Correspondingly,  the  inset  //,  C  {1..T}  for  environment  condition  Ek(x,  y)  consists  of 
all  j  such  that  k  e  ():j. 

Case  B. 

In  the  second  case,  process  y  is  also  updating  its  uk  variable.  In  this  case,  the  set  C{uk ) 
is  the  set  of  all  possible  predicates  involving  Uk[x]  and  «/, [y] .  In  other  words,  we  cannot 
predict  what  the  relationship  between  Uk[x\  and  uk[y\  is.  The  outset  consisting  of  [the 
indices  of]  environments  is  then  computed  as  described. 

In  the  abstract  model,  to  compute  the  outset  for  environment  em  we  use  Case  A  if 
the  associated  tracker  t.m  is  dirty;  otherwise  we  use  Case  B.  Observe  that,  if  the  tracker  is 
clean,  more  behaviors  are  possible. 

Denote  the  set  of  abstract  transitions  corresponding  to  the  concrete  update  transition 

(f)  by  Ix(tu).  Ix{tu )  has  a  transition  from  si  =  (pc,  ex, ..,  e-r,  h _ ,  tr,  bci, , . . ,  bcr ,  te) 

to  s 2  =  (pc',  e[, ..,  e'T,  t,\. ,  t'T)  6ci, . . . ,  bc'T)  te)  if  the  following  conditions  hold: 

UR1.  pc  =  L\,  i.e.,  the  reference  process  first  is  in  control  location  L\. 

UR2.  pc'  =  L2,  i.e.,  the  reference  process  moves  to  control  location  L2. 

UR3.  Vfc  G  [l..T\.(ek  =  1  3 j  6  Ok.e'j  =  1),  i.e.,  if  there  was  a  process  in  environ¬ 

ment  £k(x)  before  the  transition,  then  there  must  be  a  process  in  one  of  the  outset 
environments  Ok  of  Ek(x.  y)  after  the  transition. 
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UR4.  Vj  G  h-(ej  =  0  =>■  e!k  =  0),  i.e.,  if  there  is  no  process  satisfying  the  inset  environ¬ 
ments  Ik  of  environment  Ek(x.  y )  before  the  transition  then  after  the  transition  there 
can  be  no  process  in  environment  Ek{x ,  y). 

UR5.  for  each  k  G  [1..T],  the  value  of  6c'fc  is  computed  as  follows 

•  if  ek  =  0  or  k  E  Va(L2)  U  T>U(L2 )  then  bc'k  =  clean 

•  otherwise  we  have  three  cases: 

-  if  Vj  G  Ik-bcj  =  clean  then  bc'k  =  clean 

-  if  Vj  G  h-bcj  =  dirty  then  bc'k  =  dirty 

-  if  3 j  G  Ik.bcj  =  clean  and  3 j  G  Ik-bcj  =  dirty  then  bc'k  can  take  any  value 
in  (clean,  dirty,  both} 

UR6.  For  each  k  G  [1..T]  if  k  G  V(()L2)  then  t'k  =  clean  else  t'k  =  dirty  where  V(L2)  is 
either  Bx  (Q ) ,  if  the  transition  associated  with  L2  is  a  guarded  transition  with  guard 
condition  Q,  or  V(L2)  is  VU(L2),  if  the  transition  associated  with  L2  is  an  update 
transition. 

Lemma  5.5.6.  If  states  si  and  s2  in  a  concrete  system  V(K),  K  >  1,  are  such  that 

«c(-Si)  =  Si  and  ac(s2 )  =  s2,  with  c  G  [1  ..K]  and  there  is  a  transition  from  Si  to  s2 

via  process  c  executing  a  guarded  transition  tu  then  si  and  s2  satisfy  Ixifc)- 

Proof  The  proof  of  this  lemma  follows  directly  from  the  way  we  constructed  Ix(ta)-  □ 
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5.5.4  Case  4:  Update  Transition  for  Environment  Processes 


Consider  the  case  where  a  generic  process  y  satisfying  environment  E^jLl)(x,y)  is 
executing  an  update  transition 


Li  :  for  all  otr  ^  slf  if  T (slf,  otr)  then  uk  :=  $(otr) 

goto  L2 

After  the  update  transition,  process  y  will  have  a  new  control  location  and  also  the  rela¬ 
tionship  of  its  data  variables  to  those  of  the  reference  process  x  will  have  changed.  Recall 
the  notation  E(i  Ll)(x,y)  used  to  denote  the  environment  condition  y  ^  x  A  Ri(x,y )  A 
pc [y]  =  Li.  The  outset  for  environment  E(hLl)(x,  y)  will  consist  of  all  those  envi¬ 

ronments  E{jM)(x,  y)  that  process  y  may  satisfy  after  the  update  transition.  To  compute 
the  outset  0^Ll)  we  proceed  as  follows.  As  in  the  previous  case  we  find  a  fixpoint  C{uk ) 
that  contains  the  possible  relationships  between  uk[x\  and  uk[y]. 

Case  A. 

Consider  first  the  case  where  the  reference  process  is  not  updating  its  variable  uk.  The 
initial  set  of  relationships  C1(uk )  is  the  set  of  all  uk[x]  -<  uk[y\,  AG  {<,  >,  =}  such  that 

T(r/,  x)  A  uk[x]  -<  u'k[y]  is  satisfiable 

where  T (y,x)  is  the  update  condition  as  defined  in  Section  5.5.3.  Note  that  we  consider 
T (y,x)  (and  not  T (x,y)  as  in  the  previous  section)  because  y  is  the  active  process.  As 
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y  updates  its  uk  variable  repeatedly,  the  relationship  between  Uk[x\,  and  «/, [y]  will  also 
change.  To  compute  all  the  possible  relationships,  we  use  an  approach  similar  to  the 
fixpoint  computation  in  Case  3.  Thus,  we  find  the  set  C2(uk )  of  all  uk[x]  -<  uk[y],  -<E  {< 
,>,=,}  such  that 

T (y,  z )  A  uk[x\  -<  u'k[y\  A  ip(x,  y)  is  satisfiable 

where  i^>{x,y)  G  C1^).  We  similarly  compute  C3(uk),  C4(uk), . . .  until  we  reach  a 
fixpoint  C{uk). 

Case  B. 

Consider  now  the  case  where  the  reference  process  is  also  updating  its  uk  variable.  In  this 
case,  C(uk )  will  consist  of  all  possible  relations  on  uk[x)  and  uk [y\ ,  denoting  that  we  do 
not  have  enough  information. 

In  the  environment  condition  E^^Ll){x,y),  let  6  be  the  (unique)  inter-predicate  that 
describes  the  relation  between  uk[x\  and  uk  [y] .  Consider  the  set  of  environment  conditions 
E{jM)  ( x ,  y)  that  are  obtained  from  E^Ll)(x,  y)  by  replacing  9  by  a  formula  in  the  fixpoint 
C(uk)  and  replacing  the  condition  pc [y]  =  L\  by  pc[y]  =  L2.  The  indices  of  these 
environment  conditions  constitute  the  outset  of  E^tLl)(x,  y). 

To  compute  the  outset  for  an  environment  e^Ll^,  we  will  use  Case  A  if  the  associated 
backer  bc(iyLl)  is  dirty.  Otherwise,  we  use  Case  B.  Note  again  that  bc^Ll)  being  clean  or 
both  allows  more  behaviors. 

Since  the  transition  starts  at  control  location  L\  and  a  generic  process  executes  it,  we 
will  describe  the  abstract  transition  Ey’k(tu )  for  each  environment  condition  E(itLl)(x,y) 
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and  each  k  G  O^l i)-  The  abstract  transition  Iy(tu )  for  Case  4  will  be 


V  V  4‘m- 

Iyk(tu)  has  a  transition  from  .si  =  (pc.  ei, ey,  ti. . . . ,  £t,  6ci,  . . . ,  6ct,  te)  to  s2  = 

(pc',  e'j, e'T,  t\ _ ,  t'T,  bd^  . . . ,  6c'r,  te)  if  the  following  conditions  hold.  For  brevity  we 

will  represent  the  environment  condition  Si^Li)  by  £\  and  £(j,l2)  hy  £-i- 

UR1.  pc  =  pc',  i.e.,  the  reference  process  does  not  move. 

UR2.  e\  =  1,  i.e.,  there  is  a  process  in  environment  E(%.lx)(x.:]i)  before  the  transition. 

UR3.  e'2  =  1,  i.e.,  there  is  a  process  in  environment  E(j,L2)(x,y)  after  the  transition. 

UR4.  The  e  variables  except  e\,  e'2  do  not  change,  i.e.,  ei  =  ei  for  l  £  {(i,Li),  (j,L2)}. 

UR5.  Assuming  the  new  control  location  of  the  environment  process  that  moved  was 
L  G  L2,  L3,  denote  the  environment  E(r. r/)  by  Ey  The  following  conditions  must 
hold: 

•  t'2  =  u(ti,t2) 

•  t\  =  fit(e  i,fi) 

•  bc\  =  Qt(ei,bci) 

•  If  the  transition  associated  with  L  is  a  guarded  transition  6c'-  =  ,{D9(L),  be, .  bej) 

•  If  the  transition  associated  with  L  is  an  update  transition  6c'  =  nh(D"{L),  be, ,  bc.j) 
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Inter-preds 

Intra-preds 

Reachable  states 

Safety 

Bakery  (NA) 

3 

5 

O(240°) 

3800s 

Bakery  (A) 

3 

5 

0(2146) 

68.55s 

Figure  5.13:  Running  Times  for  the  bakery  protocol.  Bakery(A)  and  Bakery(NA)  stand  for  the  bakery 
protocol  with  and  without  the  atomicity  assumption 

Lemma  5.5.7.  If  states  s\  and  s2  in  a  concrete  system  'P(K),  K  >  1,  are  such  that 
ot(-Si)  =  Si  and  ac(s2)  =  s2,  with  c  G  [1  ,.K\  and  there  is  a  transition  from  Si  to  s2  via 
process  d  f  c,  executing  a  guarded  transition  tu  then  .§]  and  s2  satisfy  Iy{tjj)- 

Proof  The  proof  of  this  lemma  follows  directly  from  the  way  we  constructed  Iy(tu).  □ 


5.6  Experimental  Results 


We  applied  our  abstraction  method  to  the  Bakery  and  Szymanski’s  protocols  without 
the  atomicity  assumption.  We  were  able  to  verify  the  safety  property  of  the  Bakery  proto¬ 
col,  namely 

\/x.\/y  f  x.AG(pc[a;]  =  crit  p c[y\  f  crit) 

in  about  2  hours.  The  following  table  shows  the  run  times  and  other  statistics  in  the  non- 
atomic  case  and  the  same  verification  carried  out  under  the  atomicity  assumption 

Note  the  enormous  increase  in  the  state  space  size  once  we  remove  the  atomicity  as¬ 
sumption.  The  increase  in  the  model  checking  is  equally  dramatic.  This  again  underlines 
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the  significant  reduction  in  complexity  of  protocols  due  to  the  atomicity  assumption. 

We  were  not  able  to  verify  the  safety  property  of  Szymanski’s  protocol.  The  correct¬ 
ness  of  Szymanski’s  protocol  depends  on  the  specific  order  in  which  a  process  looks  at  the 
other  processes  in  the  system.  Szymanski’s  protocol  is  correct  only  if  a  process  looks  at  the 
other  processes  in  the  increasing  order  of  the  index  [55;  77].  The  semantics  we  assigned 
to  our  guarded  and  update  transitions  was  such  that  the  order  of  processes  was  immaterial. 
Hence  we  cannot  accurately  model  Szymanski’s  protocol  in  our  input  language. 

We  also  applied  our  abstraction  to  the  toy  protocol  described  in  Section  5.3.  As  ex¬ 
pected,  our  method  finds  a  trace  violating  the  mutual  exclusion  protocol  in  under  5  mins. 
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Chapter  6 


Verification  by  Network  Decomposition 


6.1  Introduction 

Despite  the  big  success  of  model  checking  in  hardware  and  software  verification,  the  clas¬ 
sical  approach  to  model  checking  can  handle  only  finite  state  systems.  Consequently,  ap¬ 
plying  model  checking  techniques  to  systems  involving  unlimited  concurrency,  unlimited 
memory,  or  unlimited  domain  sizes,  is  a  major  challenge.  Researchers  have  sought  to  ad¬ 
dress  these  issues  by  different  verification  methods  including,  among  others,  abstraction, 
regular  model  checking,  static  analysis,  and  theorem  proving. 

Many  software  and  hardware  systems,  however,  are  described  in  terms  of  natural  pa¬ 
rameters  and,  for  each  concrete  value  of  the  parameters,  the  systems  have  a  finite  state 
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space.  Verifying  a  property  of  a  parameterized  system  amounts  to  verifying  this  prop¬ 
erty  for  all  values  of  the  parameters.  Examples  of  parameterized  systems  include  mutual 
exclusion  protocols,  cache  coherence  protocols,  and  multi-threaded  systems. 

While  there  has  been  considerable  effort  in  verifying  parameterized  systems  such  as 
cache  protocols  and  mutual  exclusions,  that  have  replicated  but  no  underlying  network 
graphs,  there  is  little  work  on  parameterized  systems  that  have  replicated  process  and 
underlying  network  graphs.  Common  examples  of  systems  that  are  required  to  operate  on 
arbitrary  network  topologies  are  network  routing  protocols.  Leader  election  protocols,  for 
example,  are  usually  designed  to  operate  no  matter  what  the  underlying  network  topology 
of  the  system.  Verifying  such  systems  is  obviously  complicated  by  the  fact  that  the  network 
graph  can  be  arbitrary  (in  addition  to  the  fact  the  network  graph  induces  asymmetry  in  the 
system). 

In  a  seminal  paper,  Emerson  and  Namjoshi  [37]  consider  systems  composed  of  iden¬ 
tical  asynchronous  processes  which  are  arranged  in  a  ring  topology  and  communicate  by 
passing  a  Boolean  token.  For  several  classes  of  indexed  CTL*  \  X  properties  [15]  they 
provide  cutoffs ,  i.e.,  reductions  to  single  systems  of  constant  small  size.  Consequently, 
CTL*  \  X  properties  over  an  infinite  class  of  networks  can  be  reduced  to  a  single  model 
checking  call. 

In  this  chapter,  we  extend  the  results  of  Emerson  and  Namjoshi  from  rings  to  arbitrary 
classes  of  networks.  There  are  two  modifications,  however:  first,  our  results  hold  true 
only  for  LTL\X,  and  second,  we  introduce  a  more  refined  notion  of  cut-offs.  The  first 
restriction  is  necessary:  We  show  in  Section  4  that  with  CTL\X  it  is  impossible  to  obtain 
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cut-offs  for  arbitrary  networks. 

The  second  modification  actually  provides  an  interesting  new  view  on  the  notion  of  cut¬ 
offs:  in  order  to  verify  the  parametrized  system,  we  are  allowed  to  model  check  a  constant 
number  c  of  small  systems  whose  network  graphs  have  sizes  bounded  by  a  constant  s. 
Then,  the  verification  result  for  the  parametrized  system  is  a  Boolean  combination  of  the 
collected  results  for  the  small  systems.  We  call  such  a  reduction  to  a  finite  case  distinction 
a  (c,  s) -bounded  reduction. 

Our  main  results  can  be  summarized  as  follows: 

•  Verification  by  Network  Decomposition:  Verifying  systems  with  fixed  large  net¬ 
work  graphs  G  (e.g.,  concrete  instantiations  of  a  parametrized  system)  can  be  as 
challenging  as  verifying  parameterized  systems.  Note  that  when  \Q\  is  the  state 
space  of  the  individual  processes,  then  the  state  space  of  the  whole  network  can  be 
as  high  as  \Q\n,  where  n  is  the  number  of  nodes.  We  show  that  the  verification  of 
an  indexed  LTL\X  property  p  for  a  system  with  network  graph  G  can  be  achieved 
by  an  efficiently  computable  (c,  s) -bounded  reduction.  For  the  important  case  of 
2-indexed  properties,  it  is  sufficient  to  model  check  at  most  36  networks  of  size  4. 

•  Offline  Verification:  In  a  scenario  where  p  is  known  in  advance  and  the  network  G 
can  change  for  different  applications,  we  can  first  verify  a  constant  number  of  small 
systems  offline.  Later,  when  we  get  to  know  the  network  graph  G,  the  correctness 
of  G  with  respect  to  specification  p  can  be  verified  online  by  simply  evaluating  a 
constant  size  Boolean  function,  regardless  of  the  size  of  the  processes. 
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Again,  for  2-indexed  properties,  the  offline  computation  involves  at  most  36  calls  to 
the  model  checker  for  networks  of  size  4. 


•  Cut-Offs:  For  every  class  of  networks  T  and  A- indexed  LTL\X  property  ip  one  can 
verify  if  ip  holds  on  all  networks  in  T  by  a  (c,  s)-bounded  reduction,  where  c  and  s 
depend  only  on  k. 

Depending  on  the  complexity  of  the  networks  in  T,  finding  a  suitable  (c,  s)  -bounded 
reduction  will  in  general  still  involve  manual  algorithm  design.  Similar  to  famous 
results  about  linear  time  algorithms  for  bounded  tree-width  [25],  our  proofs  just 
guarantee  the  existence  of  small  reductions. 


Our  results  lay  the  foundation  for  reasoning  about  systems  with  arbitrary  network 
graphs.  While  communication  between  the  processes  is  simple,  the  results  we  obtain  are 
non-trivial.  In  fact,  we  were  surprised  to  discover  that  for  CTL\  X  specification  there  are 
no  cutoffs  even  for  the  simple  communication  model.  The  generalized  notion  of  cutoffs  we 
present  will  be  crucial  to  reasoning  about  systems  with  more  complicated  communication. 

This  chapter  is  organized  as  follows:  the  next  section  contains  the  work  closest  to  our 
work.  In  Section  3,  we  describe  the  system  model  in  detail.  Section  4  contains  the  main 
cutoff  results.  Section  5  shows  that  no  cutoffs  exist  for  CTL  \  X.  Finally,  the  conclusion 
in  Section  5  briefly  considers  further  performance  enhancements  for  practical  applications 
of  our  method. 
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6.2  Related  Work 


Verification  of  parameterized  systems  is  well  known  to  be  undecidable  [2;  76].  Many 
interesting  approaches  to  this  problem  have  been  developed  over  the  years,  including  the 
use  of  symbolic  automata-based  techniques  [1;  10;  12;  13;  51;  78],  network  invariants 
[3;  64],  predicate  abstraction  [52;  53],  and  symmetry  reduction  [24;  31;  38;  39;  40].  In 
[11],  cut-offs  were  used  for  the  verification  of  systems  sharing  common  resources,  where 
the  access  to  the  resources  is  managed  according  to  a  FIFO-based  policy. 

In  addition  to  [37]  mentioned  above,  Emerson  et  al.  have  shown  a  large  number  of  fun¬ 
damental  results  involving  cut-offs.  The  paper  [33]  by  Emerson  and  Kahlon  also  considers 
LTL\X  cut-offs  for  arbitrary  network  topologies  with  multiple  tokens,  but  each  token  is 
confined  to  two  processes  which  renders  their  model  incomparable  to  ours.  Other  previ¬ 
ous  work  by  Emerson  and  Kahlon  [32;  34;  35]  consider  other  restricted  forms  of  process 
interaction.  Finally,  [43]  considers  the  verification  of  single  index  properties  for  systems 
with  multiple  synchronous  processes. 

Indexed  temporal  logic  was  introduced  in  [15].  The  paper  also  considers  identical 
processes  arranged  in  ring  topology. 

The  work  that  is  closest  in  spirit  to  our  negative  results  on  CT L*  \  X  logic  is  the  work 
by  Browne,  Clarke  and  Grumberg  in  [14]  that  shows  how  to  characterize  Kripke  structures 
up  to  bisimilarity  using  fragments  of  CTL*.  Our  results  show  that  even  CTL*  \  X  with 
only  two  atomic  propositions  is  sufficient  to  describe  an  infinite  class  of  Kripke  structures 
that  are  not  bisimilar  to  each  other.  In  other  words,  bisimilarity  over  the  class  of  Kripke 
structures  with  two  labels  gives  rise  to  an  infinite  number  of  equivalence  classes. 
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6.3  Computation  Model 


Network  Topologies.  A  network  graph  is  a  finite  directed  graph  G  =  (S,  C)  without 
self-loops,  where  S  is  the  set  of  sites ,  and  C  is  the  set  of  connections.  Without  loss  of 
generality  we  assume  that  the  sites  are  numbers,  i.e.,  S  =  {1,2,...,  \S\}.  A  (network) 
topology  T  is  a  class  of  network  graphs. 

Token  Passing  Process.  A  single  token  passing  process  P  (process)  is  a  labeled  transition 
system  (Q,H,  6, 1)  such  that: 

•  Q  =  Q  x  B,  where  Q  is  a  finite,  nonempty  set  and  B  =  {0, 1}.  Elements  of  Q 
will  be  called  local  states.  The  boolean  component  of  a  local  state  indicates  the 
possession  of  the  token.  We  say  that  a  local  state  (q,  b )  holds  the  token  if  b  —  1. 

•  E  =  EjU£dU{rcv,  snd}  is  the  set  of  actions.  The  actions  in  £d  are  token  dependent 
actions,  those  of  £/  are  called  token  independent  actions,  and  {rev,  snd}  are  actions 
to  receive  and  send  the  token.  The  sets  £y,  are  mutually  exclusive. 

•  5CQxSxQisa  transition  relation,  such  that  every  ((q,  b ),  a,  (q',  b'))  G  5  fulfills 
the  following  conditions: 

(a)  A  free  transition  does  not  change  token  possession:  a  6  E/ fc  =  5' 

(b)  A  dependent  transition  can  execute  only  if  the  process  possesses  the  token: 

a  b  =  b'  =  1 

(c)  A  receive  establishes  possession  of  token:  a  =  rev  b  =  0,  b'  =  1 

(d)  A  send  revokes  the  possession  of  token:  a  =  snd  =>  b  —  1,  b'  —  0 
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•  I  C.  Q  is  the  set  of  initial  states. 


Topological  Composition.  Let  G  =  (.S',  C)  be  a  network  graph  and  P  =  {(),  E,  S,  I) 
be  a  single  token  process.  Then  PG  denotes  the  concurrent  system  containing  n  =  ,5' 
instances  of  P  denoted  by  Ps,  s  G  S.  The  only  synchronization  mechanism  between  the 
processes  is  the  passage  of  a  token  according  to  the  network  graph  G.  Formally,  the  system 
PG  is  associated  with  a  transition  system  (Q,  A,  I)  defined  as  follows: 

•  Q  =  {(91, _ ,  qn)  €  Qn  |  exactly  one  of  the  q,  holds  the  token}. 

•  AC  Q2n  is  defined  as  follows:  a  transition  (qi,  q2, . . . ,  qn )  — >  (q[,  q'2,  ■  ■  ■ ,  q'n)  is  in 
A  in  one  of  two  cases: 

(a)  Asynchronous  Transition:  there  exist  an  index  j  e  (1, . . . ,  n}  and  an  action 
a  G  £/  U  Tjd  such  that  (qv  a,  q'j )  G  d,  and  for  all  indices  i  ^  j  we  have  q,  =  q1,  . 
In  other  words,  only  process  Pj  makes  a  transition  (different  from  a  send  or 
receive). 

(b)  Token  Transition:  there  exist  a  network  connection  (j,  k)  G  C  in  the  network 
graph,  such  that  (qj:  snd,  q'-)  G  S,  (qk,  rev,  q'k)  G  <5,  and  q,  =  q[  for  all  indices  i 
different  from  j,  k. 

•  1  =  {(gi, . . . ,  qn)  G  In  |  exactly  one  of  the  q,  holds  the  token}. 

An  execution  path  is  considered  fair  if  and  only  if  every  process  P,  receives  and  sends  the 
token  infinitely  often.  We  assume  that  every  system  PG  that  we  consider  has  fair  paths.  An 
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immediate  consequence  of  the  fairness  condition  is  that  a  system  PG  can  have  fair  paths 
only  if  G  is  strongly  connected. 

We  shall  use  indexed  temporal  logics,  which  can  refer  explicitly  to  the  atomic  propo¬ 
sitions  of  each  process  Pt,  to  specify  properties  of  the  compound  systems.  For  each  local 
state  q  in  Q  we  introduce  propositional  variables  g(l), . . . ,  q(n).  The  atomic  proposition 
q{i)  says  that  process  Pi  is  in  state  q.  Thus,  for  a  global  state  g  we  define 

g  \=  q(i )  iff  in  global  state  g,  process  Pi  is  in  state  q. 

Starting  from  this  definition  for  atomic  propositions,  we  can  easily  define  common  tempo¬ 
ral  logics  such  as  CTL  or  LTL  in  a  canonical  way.  Throughout  this  paper,  we  will  assume 
that  the  path  quantifiers  A  and  E  quantify  over  fair  paths.  Further  we  assume  that  LTL 
formulas  are  implicitly  quantified  by  E.  This  restriction  simplifies  our  proofs  but  does  not 
restrict  generality. 

Example  6.3.1.  The  formula  G(g(l)  =>•  Fg(2))  says  that  whenever  process  Pi  is  in  state 
q  then  process  P2  will  be  in  state  q  sometime  in  the  future. 

For  increased  expressibility  we  permit  that  in  an  atomic  formula  q(x)  the  process  index 
a;  is  a  variable  (called  index  variable )  which  can  take  any  value  from  1  to  |  -S' | ,  the  total  num¬ 
ber  of  processes.  Thus,  x  can  refer  to  arbitrary  processes.  We  shall  write  . . . ,  xn) 
to  indicate  that  the  temporal  formula  depends  on  the  index  variables  X\1 . . .  xn.  We  can 
substitute  the  index  variables  in  a  formula  <p(x i, . . . ,  Xk)  by  integer  values  /  | ?/r  in  the 
natural  way,  and  denote  the  resulting  formula  by  . . .  ,4). 

In  addition  to  substitution  by  constants,  we  can  also  quantify  over  the  index  variables 
xi,...xn  using  a  prefix  of  existential  and  universal  quantifiers  with  the  natural  seman- 
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tics.  Such  formulas  are  called  quantified  temporal  formulas.  For  example,  the  formula 
\/x3y.ip(x ,  y)  means  “For  all  processes  x  there  exists  a  process  y,  such  that  the  temporal 
formula  <p(x,  y)  holds.”  A  formula  without  quantifier  prefix  is  called  quantifier-free .  If  all 
index  variables  in  a  formula  are  bound  by  quantifiers  we  say  that  the  formula  is  closed , 
and  open  otherwise.  The  quantifier-free  part  of  a  quantified  formula  is  called  the  matrix  of 
a  formula. 

Example  6.3.2.  The  formula  Eta,  y.G(q(x)  =>•  F q(y))  says  that  there  exist  two  processes 
Px  and  Py,  such  that  whenever  process  Px  is  in  state  q  then  process  Py  will  be  in  state  q 
some  time  in  future. 

The  formal  semantics  of  this  logic  is  straightforward  and  is  omitted  for  the  sake  of 
brevity. 

Definition  6.3.3  (A-indexed  Temporal  Formula).  Let  £  be  a  temporal  logic.  A  A  - indexed 
temporal  formula  is  a  formula  whose  matrix  refers  to  at  most  k  different  processes,  i.e., 
there  are  at  most  k  different  constant  indices  and  index  variables. 


6.4  Reductions  for  Indexed  LTL\X  Specifications 

In  this  section,  we  will  show  how  to  reduce  the  model  checking  question  PG  |=  p  to  a 
series  of  model  checking  questions  on  smaller  systems  PGi' s  where  we  can  bound  the  size 
of  the  network  graphs  Gi  as  well  as  the  number  of  the  Gf  s.  For  the  sake  of  simplicity,  we 
will  start  with  the  special  case  of  2-indexed  existential  LTL\X  specifications,  which  can 
be  readily  generalized  to  the  full  case. 
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6.4.1  Existential  2-indexed  LTL\X  Specifications 


In  this  section  we  show  how  to  verify  simple  2-indexed  LTL\X  properties  of  the  form 
3 i,j.(p(i,j),  where  i  ^  j.  We  will  use  the  insights  we  obtain  from  this  case  to  obtain  the 
more  general  results  later  on. 

Recall  that  2-indexed  properties  are  concerned  only  with  properties  of  two  processes 
in  a  given  system.  Our  process  communication  model  implies  that  two  processes  Pi  and 
Pj  can  only  affect  each  other  by  passing  or  receiving  a  token.  Consequently,  the  synchro¬ 
nization  between  Pt  and  Pj  crucially  depends  on  the  paths  between  sites  i  and  j  in  the 
network  graph.  The  following  example  is  crucial  to  understanding  the  intuition  behind  our 
approach: 

Example  6.4.1.  The  Figure  below  shows  one  path  n  —  i,  a,  b,  i ,  j,  b,  c,  i,  c,  j, . . .  that  the 
token  takes  in  a  network  graph. 

i  a  b  i  j  b  c  ic  j 

O - 3-0 - 3-0 - 3—  O - 3-0 - 3-0 - 3—  o - 3—  O - 3-  O - 3-0 . 3- 

/  \  A  \  4  \  A 

*0  (*>.?)  ® > — ►  (j.  *) 

Suppose  that  we  are  only  interested  in  properties  concerning  the  processes  Pj  and  Pj, 
but  not  in  processes  Pa,  Pb,  Pc.  Then  only  the  sequence  of  the  V s  and  j’s  in  the  path  are 
of  interest.  Looking  at  7r  from  left  to  right,  we  see  four  possibilities  for  what  can  happen 
between  i  and  j:  (1)  Pi  sends  a  token,  and  receives  it  back  without  Pj  seeing  it  (formally, 
we  will  write  $0(i,  j)  to  denote  this);  (2)  P,  passes  the  token  directly  to  P3  j)); 

(3)  Pj  sends  the  token  to  P,  through  several  intermediate  sites  *));  and  (4)  P,  sends 
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the  token  back  to  Pj  through  several  intermediate  sites  j)).  There  are  two  more 

possibilities  which  do  not  occur  in  it:  (5)  i)  and  (6)  *)•  The  important  insight 

is  the  following:  If  we  know  which  of  these  6  cases  can  occur  in  a  network  graph  G, 
then  we  have  all  information  needed  to  reason  about  the  communication  between  P, 
and  Pj. 

We  will  later  construct  small  network  graphs  with  4  nodes  where  the  sites  i  and  j  are 
represented  by  two  distinguished  nodes  site i  and  site2,  while  all  other  sites  are  repre¬ 
sented  by  two  “hub”  nodes  hubi  and  hub-2. 

This  example  motivates  the  following  definitions: 

Definition  6.4.2  (Free  Path).  Let  I  be  a  set  of  indices,  and  it  be  a  path  in  a  network  graph 
G.  We  say  that  it  is  I- free,  if  tt  does  not  contain  a  site  from  I. 

We  now  define  three  kinds  of  path  types  that  will  be  shown  to  capture  all  relevant  token 
paths  between  two  processes  PL  and  P;. 

Definition  6.4.3  (Connectivity,  Characteristic  Vectors).  Let  i,j  be  indices  in  a  network 
graph  G.  We  define  three  connectivity  properties  of  the  indices  i.  j: 

G  |=  j )  ’’There  is  a  {j} -free  path  from  i  to  itself.” 

G  |=  j)  ’’There  is  a  path  from  i  to  j  via  a  third  node  not  in  {i,  j}.” 

G  |=  j)  ’’There  is  a  direct  edge  from  i  to  j.” 

Using  the  connectivity  properties,  we  define  an  equivalence  relation  ~2  on  network  graphs: 
Given  two  network  graphs  G\  and  G->  along  with  two  pairs  of  indices  a  \.b\  and  a2,b2,  we 
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define 


(Gi,ai,bi)  ~2  {G2,a2,  62) 
iff  for  every  $  e  {$0,  $^}, 

Gi  [=  $(oi,&i)  G2  |=  $(02,  b2)  and 

Gi  |=  $(61,01)  -<=r>  G2  |=  $(62,02) 

If  (G 1,  oi,  61)  ~2  (G2,  a2,  62)  we  say  that  the  indices  ai,  61  in  Gi  have  the  same  con¬ 
nectivity  as  the  indices  a2,  b2  in  G'2. 

The  characteristic  vector  v(G\ .  «|  .b\  )  is  the  6-tuple  containing  the  truth  values  of 

G\  \=  $0(01,  h\),  G\  \=  <Moi,  hi),  Gi  \=  $— > (o  1 , 61)  Gi  [=  $0(61,  ai),  Gi  \=  $^(61,  ai), 

and  Gi  [=  $^>(6i,  ai), 

By  definition  it  holds  that  (Gi,  Oi,  bi)  ~2  (G'2,  a2,  62)  iff  they  have  the  same  character¬ 
istic  vectors,  i.e.,  v(G  1,  Oi,  61)  =  v(G2,  a2,  b2).  Since  the  number  of  characteristic  vectors 
is  constant,  it  follows  that  ~2  has  finite  index.  The  characteristic  vectors  can  be  viewed  as 
representatives  of  the  equivalence  classes. 


hub2  hub2 


hubi  hubi 


Figure  6.1:  Network  Graphs  A,  B,  realizing  two  different  characteristic  vectors 
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Example  6.4.4.  Consider  the  network  graphs  A,  B  of  Figure  6.1.  It  is  easy  to  see  that 
(A,  site i,  site2 )  has  characteristic  vector  (1, 1, 1, 1, 1, 1),  i.e., 

A  |=  i,  site 2)  A  &~^(site i,  site 2)  A  &^(site i,  site 2)  A 

<FC3(site2,  site i)  A  sitei)  A  <F^(site2,  sitei) 

and  (5,  sitei,  site2)  has  characteristic  vector  (0, 1,  0, 1, 1,  0),  i.e., 

B  |=  site2 )  A  <&^(site i,  site2)  A  -i<F^(sitei,  site2)  A 

<F(j(site2,  sitei)  A  <F^(site2,  sitei)  A  -> &^(site2,  site i). 

Note  that  a  network  graph  will  in  general  have  several  characteristic  vectors  depending 
on  the  indices  we  consider.  The  set  of  characteristic  vectors  of  a  graph  G  can  be  effi¬ 
ciently  computed  from  G  in  quadratic  time.  The  crucial  insight  in  our  proof  is  that  for 
two  processes  Pi  and  Pj,  the  connectivity  between  their  indices  i.j  in  the  network  graph 
determines  the  satisfaction  of  quantifier-free  LTL\X  properties  p(i,j)  over  PG'- 

Lemma  6.4.5  (2-Index  Reduction  Lemma).  Let  G i,  G2  be  network  graphs,  P  a  process, 
and  <p(x,  y )  a  2 -indexed  quantifier-free  LTL\X  property.  Let  ai,  hi  be  a  pair  of  indices  on 
G\,  and  a2lb2  a  pair  of  indices  on  G2.  The  following  are  equivalent: 

(a)  (Gi,  ai,  h\)  ~2  (G2,  a2,  b2),  i.e.,  ai,b\  and  a2,  b2  have  the  same  connectivity. 

(b)  PGl  \=  (p(ai,  hi)  iff  PG2  |=  p(a2,b2). 

Proof  of  this  lemma  and  other  claims  in  this  chapter  have  been  moved  to  the  last  section 
for  better  readibility. 
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The  lemma  motivates  the  following  model  checking  strategy:  Given  a  (possibly  com¬ 
plicated)  network  graph  G\  and  two  of  its  sites  i.  j,  we  can  try  to  obtain  a  simpler  network 
G2  :=  with  two  special  nodes  site i  and  site2  that  have  the  same  connectivity  in  G2 

as  the  indices  i  and  j  in  G\,  and  thus  satisfies  condition  (a)  of  the  lemma.  For  the  case  of 
two  indices,  we  can  always  find  such  a  network  graph  Gy^\  with  at  most  4  sites. 

Proposition  3.  For  each  graph  G  and  indices  i,j  there  exists  a  4-node  graph  Gyj)  called 
the  connection  topology  ofi,j,  having  two  special  sites  site l  and  site2  such  that 

(G,i,j)  ~2  (G(ijj),site1,site2). 

In  other  words,  the  indices  i  and  j  in  G  have  the  same  connectivity  as  the  indices  site i  and 
site2  in  Gyjy 


Since  Gyj)  satisfies  condition  (a)  of  Lemma  6.4.5,  we  obtain  the  following  important 
consequence: 

Corollary  6.  Let  (p(i,j)  be  a  2-indexed  quantifier-free  LTL\X  property.  Then 

PG\=p(i,j)  iff  PG^’^  \=  cp(sitei,  site2). 

Thus,  we  have  achieved  a  reduction  from  a  potentially  large  network  graph  G  to  a  4- 
node  network  graph  G^jy  We  will  now  show  how  to  actually  construct  the  connection 
topology  G(ijy 

Construction  of  G^jy  We  construct  the  reduction  graphs  as  follows.  G(UJ)  has  four 
sites:  site i,  site2 ,  h  ub] .  and  hub2.  The  sites  site i  and  site2  are  called  primary  sites.  They 
represent  the  sites  of  interest  i  and  j.  The  other  sites  are  called  hubs,  and  they  represent 
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the  other  nodes  of  the  graph  G.  Let  us  describe  in  more  detail  the  role  of  these  different 
nodes.  Recall  that  to  satisfy  Proposition  3,  the  sites  site i  and  site2  in  should  have 
the  same  connectivity  as  i,j  in  G.  Therefore: 

•  If  (i ,  j )  holds  in  G  (i.e.,  there  exists  a  path  from  i  to  j  in  G  that  goes  through  a 

third  node),  then  $^(site i,  site2)  has  also  to  hold  in  G^j),  i.e.,  there  should  exist 
in  Guj)  a  path  from  site i  to  site2  that  goes  through  a  third  node.  The  site  hubi  will 
play  the  role  of  this  “third  node”.  Therefore,  in  this  case,  G^j)  contains  an  edge 
from  site i  to  hubi,  and  from  hubi  to  site2. 

•  In  the  same  manner,  if  ^(i,  j)  holds  in  G  (i.e.,  there  exists  a  path  from  i  to  itself 
in  G  that  does  not  go  through  j),  then  <f>0(site i,  site2 )  should  also  be  true  in  G^j). 
As  previously,  this  is  ensured  by  considering  the  following  edges:  (site i,  hubi )  and 
( hubi ,  site i). 

•  Finally,  if  (i-.j)  holds  in  G  (i.e.,  there  exists  a  direct  edge  in  G  from  i  to  j),  then 
G(ij)  should  also  contain  the  edge  (site i,  site2). 

•  The  paths  from  j  to  i  are  treated  in  a  symmetrical  way. 

For  example,  let  H  be  a  graph  having  as  sites  i,j,  k,  and  l  (among  others),  such  that 
v(H,  i,j)  =  (1, 1, 1, 1, 1, 1),  and  v(H ,  k,  l)  =  (0, 1,  0, 1, 1,  0);  then  the  graphs  A  and  B  of 
Example  6.4.4  correspond  respectively  to  the  reduction  graphs  ^  and 

Since  our  fairness  assumption  implies  that  the  network  is  strongly  connected,  not  all  char¬ 
acteristic  vectors  actually  occur  in  practice.  A  closer  analysis  yields  the  following  bound: 
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Proposition  4.  For  2  indices,  there  exist  at  most  36  connection  topologies. 

All  the  36  connection  topologies  are  shown  in  the  Section  6.8. 

Let  us  now  return  to  the  question  of  verifying  properties  of  the  form  3x,  y.<p(x,  y ).  Note 
that  Corollary  6  only  provides  us  with  a  way  to  verify  one  quantifier-free  formula 
Given  a  system  PG,  we  define  its  2-topology,  denoted  by  T2(G),  as  the  collection  of  all 
different  connection  topologies  appearing  in  G.  Formally, 

Definition  6.4.6.  Given  a  network  graph  G  =  (S,  C ),  the  2-topology  of  G  is  given  by 

T2(G)  =  {G(jj)  \i,j  eS,i^  j}. 

By  Proposition  4,  we  know  that  \T2(G)  \  <  36.  Since  we  can  express  3x,  y.<p(x,  y)  as  a 
disjunction  \J  i  jeS  ip(i ,  j)  we  obtain  the  following  result  as  a  consequence  of  Corollary  6: 

Theorem  6.4.7.  The  following  are  equivalent: 

(i)  PG  h  3x,y.tp{x,y) 

(ii)  There  exists  a  connection  topology  T  e  T2(G),  such  that  P 7  \—  p(site i,  site2). 

Thus,  we  obtain  the  following  reduction  algorithm  for  model  checking  P°  (=  3x,  y.p(x.  y) 
1 :  Determine  T2  ( G ) . 

2:  For  each  T  e  T2(G),  model  check  PT  [=  ip(site i,  site2). 

3:  If  one  of  the  model  checking  calls  is  successful  then  output  “true”  else  output 
“false”. 
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Example  6.4.8. 


Q — Q 


6 — O 


Figure  6.2:  A  system  with  grid  like  network  graph  with  9  nodes. 

Consider  a  system  PG  with  a  grid  like  network  graph  G  shown  in  Figure  6.2.  Assume 
that  each  edge  of  the  network  is  bidirectional.  To  verify  a  2-indexed  LTL  \  X  property 
3x,  y.(p(x,  y )  of  this  system,  it  is  enough  to  consider  two  systems  PGl  and  P°2  with  net¬ 
work  graphs  G\,  G2  shown  in  Figure  6.3  and  check  ip  (site  i,  site  2)  on  each  of  them. 

If  either  system  satisfies  <p(site  1,  site 2)  then  PG  \=  3x,  y.<p(x ,  y).  Otherwise,  it  PG  ^ 
3x,y.<p(x,y). 


Relation  with  Environment  Abstraction 

In  this  section  we  will  consider  the  relationship  between  the  decomposition  presented  here 
and  environment  abstraction  presented  in  the  earlier  chapters.  For  ease  of  comparison,  we 
will  consider  environment  abstraction  with  single  reference  process  and  decompositions 
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hub. 


hub. 


site2 


Figure  6.3:  Connection  topologies  for  the  grid-like  network  graph. 

for  two  indexed  properties. 

First  note  that  both  the  methods  deal  with  properties  of  a  fixed  number  of  processes. 
In  the  case  of  environment  abstraction,  we  considered  primarily  single  index  properties, 
that  is,  properties  of  one  process  and  its  environment.  Here  we  consider  double  indexed 
properties,  that  is  properties  satisfied  by  two  processes  and  their  common  environment.  To 
build  the  abstract  model  in  environment  abstraction,  we  begin  by  asking  how  the  system 
looks  when  viewed  from  the  reference  process.  The  environment  of  the  reference  process 
is  captured  using  an  appropriately  chosen  set  of  predicates.  Our  soundness  theorem  of 
Chapter  2  shows  that  the  abstract  model  built  using  these  predicates  is  sound  and  our 
experiments  show  that  the  abstract  models  are  quite  precise. 

In  this  chapter  too,  we  ask  how  the  system  looks  like  from  the  point  of  view  of  two 
processes.  But  this  time,  the  environment  around  the  two  processes  is  described  mainly 
in  terms  of  the  network  topology.  Note  that  the  reduced  system  PG«j)  corresponding  to 
processes  i,j  in  a  system  PG  can  be  thought  of  as  an  abstraction  of  PG .  But,  unlike 
usual  abstractions,  the  set  of  properties  (involving  only  processes  i,j )  satisfied  by  PG(^) 
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is  exactly  the  same  as  the  set  of  properties  satisfied  by  PG. 

One  way  of  looking  at  environment  abstraction  is  to  first  consider  the  abstract  models 
obtained  by  fixing  the  reference  process  (as  we  do  in  the  proof  of  soundness).  That  is,  for 
a  given  system  V(K)  consider  the  abstract  models  VA, . . . ,  V^.  If  we  can  show,  for  each 
i  e  [1  ..K\, 

Vf  h  t(i) 

then  we  can  conclude  that 

V(K)  |=  Vx.$(x) 

But,  it  is  not  feasible  to  check  each  of  the  abstract  models  Vf  individually  because  there 
is  no  bound  on  K.  So  instead  of  verifying  each  abstract  model  separately,  we  create  a  new 
abstract  model  VA  by  combining  all  the  individual  models  VA, . . . ,  VA  to  obtain  an  even 
more  abstract  model.  By  the  existential  abstraction  principle,  we  have 

VA  \=  $(x)  ^  \/i.VA  |=  $(i) 

Thus,  it  is  enough  to  verify  the  abstract  model  VA. 

In  contrast,  in  this  chapter,  we  take  every  possible  pair  of  processes  i,  j,  and  construct 
the  abstract  model  PG^i)  specific  to  each  of  them.  But  then,  instead  of  grouping  all  these 
abstract  models,  we  keep  them  separate  and  check  each  of  them  individually.  This  is  pos¬ 
sible  because  Proposition  4  guarantees  that  there  are  only  36  different  possible  reduction 
graphs  (or  abstract  models).  This  could  not  be  done  in  the  case  of  environment  abstrac¬ 
tion,  because  we  don’t  know  apriori  how  many  different  individual  abstract  models  are 
there  nor  do  we  know  how  to  find  them  efficiently. 
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To  summarize,  the  reduction  presented  here  and  the  environment  abstraction  both  in¬ 
volve  describing  the  world  around  a  fixed  number  of  processes.  Importantly,  the  results 
presented  in  this  chapter  amount  to  reductions,  that  is  ,  the  properties  under  consideration 
are  preserved  exactly.  In  contrast,  in  environment  abstraction,  the  abstract  model  exhibits 
more  behaviors  than  the  concrete  system. 

6.4.2  Existential  k-indexed  LTL\X  Specifications 

We  will  now  show  how  to  generalize  the  results  of  the  previous  section  to  A  - indexed  prop¬ 
erties.  Throughout  this  section,  we  will  write  expressions  such  as  i  to  denote  A  -tuplcs  of 
indices,  and  x  to  denote  A  -tuples  of  variables.  We  will  first  adapt  the  notion  of  connectivity 
as  follows.  Let  i  —  4,  i2  . . .  4  be  a  sequence  of  indices,  and  /  =  {4, 4  •  •  •  4-}-  Then  we 
define  the  following  connectivity  properties: 

G  \=  /)  ’’There  is  an  (/  \  {x})-free  path  from  x  to  itself.” 

G  f=  y,  I)  ’’There  is  a  path  from  x  to  y  via  a  third  node  not  in  /.” 

G  \=  y)  ’’There  is  a  direct  edge  from  x  to  yT 

By  instantiating  the  variables  x  and  y  by  the  indices  4,  •  •  • ,  4-  in  all  possible  ways,  we  ob¬ 
tain  a  finite  number  of  different  conditions  which  will  describe  all  possible  connectivities 
between  the  indices  4,  •  •  •  ,  4- 

As  in  the  previous  section,  we  can  define  an  equivalence  relation  where  (  64  i) 
(G4  j)  iff  the  indices  i  have  the  same  connectivity  in  G  \  as  the  indices  j  in  G4  Since  the 
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Figure  6.4:  An  example  of  a  5-index  connection  topology 

number  of  conditions  is  bounded,  is  an  equivalence  relation  of  finite  index,  and  we  can 
describe  each  equivalence  class  by  a  characteristic  vector  v(G,  v).  As  in  the  previous  sec¬ 
tion,  we  define  the  /c-connection  topologies,  G^l!i2_._ik)  of  the  processes  Pn ,  Pl2 . . .  Pik  in 
G  as  the  smallest  graphs  that  preserve  all  the  connectivity  properties  between  the  processes 
Pix,  Pi2 . . .  Pik.  The  construction  of  the  topology  graphs  is  illustrated  in  Figure  6.4. 

The  unfilled  nodes  site i, . . . ,  sitek  in  the  graph  are  the  primary  sites.  There  is  a  hub 
site  associated  with  each  primary  site.  Moreover,  there  is  an  edge  from  each  hub  hubj 
back  to  its  primary  sitej  if  there  is  an  (/  \  {ij})-free  path  from  ij  to  itself.  There  is  an  edge 
from  hubj  to  sitei  if  there  is  a  path  from  ij  to  ii  in  G  via  a  third  node  not  in  /,  and  there  is 
an  edge  from  sitej  to  sitei  if  there  exists  a  direct  edge  (ij,  ii )  in  G. 

Analogous  to  the  bounds  on  2-connection  topologies  it  can  be  shown  that  each  k- 
connection  topology  has  at  most  2k  processes  and  that  there  are  at  most  3k(k~1)2k  distinct 
/c-connection  topologies.  By  an  argument  analogous  to  that  of  the  previous  section,  we 
obtain  the  following  corollary 
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Corollary  7.  Let  (p(x)  be  a  A  -i  indexed  quantifier-free  LTL\X  property.  Then 

PG  [=  tp(i)  iff  PGU)  |=  Lp[site i,  site 2, . . . ,  site *,). 

The  notion  of  A;-topology  is  defined  analogously: 

Definition  6.4.9.  Given  a  network  graph  G  =  (S',  G)  the  k-topology  of  G  is  given  by 
Tk(G )  =  {G(?)  |  i  G  S^',  all  indices  in  i  are  distinct}. 

Consequently,  we  obtain  a  model  checking  procedure  from  the  following  theorem, 
similar  to  the  case  of  2-indices: 

Theorem  6.4.10.  The  following  are  equivalent: 

(i)  PG  \=  3 x.(p(x) 

(ii)  There  exists  a  connection  topologyT  G  Tk(G),  such  that  PT  \=  (p(site  1,  site  2, . . . ,  site^ ). 
As  mentioned  before  \Tk(G)\  <  3fc(fc-1)2fc. 

6.4.3  Specifications  with  General  Quantifier  Prefixes 

In  this  section  we  will  show  how  to  obtain  reductions  for  /c-indexed  specifications  with 
first  order  prefixes. 

Let  us  for  simplicity  consider  the  2-indexed  formula  $  :=  Vx3 y.ip(x,y).  Over  a 
network  graph  G  =  ( S,C ),  \S\  =  n,  it  is  clear  that  $  is  equivalent  to  Ai<j<n  Vi<j<n 
< p(i,j ).  A  naive  application  of  Corollary  7  would  therefore  require  n2  calls  to  the  model 
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checker,  which  may  be  expensive  for  practical  values  of  n.  In  practice,  however,  we  can 
bound  the  number  of  model  checker  calls  by  \T2(G)  |  since  this  is  the  maximum  number  of 
different  connection  topologies.  We  conclude  that  the  n2  model  checker  calls  must  contain 
repetitions.  We  can  make  sure  that  at  most  36  calls  to  the  model  checker  are  needed.  We 
obtain  the  following  algorithm: 

1:  Determine  T2(G). 

2:  For  each  T  G  T2(G) 

3:  model  check  PJ  |=  ip(sitei,  site2) 

4:  g[T]  1  iff  model  checking  successful,  and  0  otherwise 

5:  Output  Aixi<n  \fi<j<n9[G(ij)]. 

By  simplifying  the  formula  in  line  5,  we  may  further  increase  performance.  The  algo¬ 
rithm  can  be  adapted  for  k  indices  in  the  obvious  way.  To  state  the  main  theorem  of  this 
section,  we  define  (c,  s) -bounded  reductions,  where  c  bounds  the  number  of  calls  to  the 
model  checker,  and  s  bounds  the  size  of  the  network  graph. 

Definition  6.4.11  ((c,  s  j -bounded  Reduction).  Let  G,  P  be  as  above,  and  g)  be  a  closed 
^-indexed  formula  with  matrix  ,  a'/,.).  Let  T  denote  a  property  of  interest  (e.g., 

the  model  checking  property  "PG  \—  ff').  A  (c,  s) -bounded  reduction  of  property  T  is 
given  by: 

•  a  sequence  of  c  reduced  network  graphs  Gt  =  [Si,  Ci ),  1  <  i  <  c  such  that  \Si\  <  s. 
called  reduction  graphs. 
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•  a  boolean  function  B  over  c  variables  gi, ...  ,gc,  such  that 


'h  iff  B(gu  ...,gc)  =  1  where  gt  :=  1  iff  G?  f=  p'(site  i, . . . ,  sitek ) 

In  other  words,  property  'k  is  decided  by  c  calls  to  the  model  checker,  where  in  each 
call  the  network  graph  is  bounded  by  s. 

Further,  we  say  that  a  class  C  of  specifications  has  (c,  s)  bounded  reduction  if  for  all 
network  graphs  G  and  any  p  e  jC,  the  property  PG  (=  p  has  (c,  .s  j-boundcd  reduction.  We 
can  now  state  our  main  result: 

Theorem  6.4.12.  Let  p  be  any  k-indexed  LTL\X  specification.  Then  the  model  checking 
problem”  PG  f=  p"  has  polynomial-time1  computable  l)2/,:.  2k)-bounded  reductions. 

In  fact,  the  sequence  of  reduced  network  graphs  is  just  the  different  /^-connection  topolo¬ 
gies  occurring  in  G.  This  implies  that  given  k  and  network  graph  G,  all  A  - indexed  LTL\X 
specifications  have  the  same  reduction.  Stated  another  way,  LTL\X  has  (3fc(fc-ri2fc,  2k)- 
bounded  reduction. 

6.4.4  Cut-Offs  for  Network  Topologies 

In  this  section,  we  prove  the  existence  of  cutoffs  for  network  topologies,  i.e.,  (infinite) 
classes  of  network  graphs.  We  say  that  a  class  of  network  graphs  has  cutoff  (c,  s),  if  the 
question  whether  all  the  network  graphs  in  this  topology  satisfy  the  specification  has  a 
(c,  s) -bounded  reduction. 

'in  the  size  of  the  network  graph  G 


228 


Definition  6.4.13  (Cut-off).  Let  T  be  a  network  topology,  and  C  a  class  of  specifications. 

T  has  a  cut-off  (c,  s)  for  C  if  for  all  specifications  p  6  C  the  property 

'L  ;=  “VGeT.P0^” 

has  a  (c,  s) -bounded  reduction. 

It  is  not  hard  to  prove  that  a  (c,  s) -bounded  reduction  for  a  network  graph  translates  to 
a  cut-off  for  a  network  topology: 

Theorem  6.4.14.  For  k-indexed  specifications,  all  network  topologies  T  have  (2k,  ‘.]k(k-  l  )2k)- 
bounded  reductions. 

Note  that  the  theorem  does  not  provide  us  with  an  effective  means  to  find  the  reduc¬ 
tion;  it  does  however  guarantee  that  at  least  in  principle  we  can  always  find  a  cutoff  by 
investigating  the  topology  T. 


6.5  Bounded  Reductions  for  CTL\X  are  Impossible 

In  this  section,  we  show  that  indexed  CTL\  X  formulas  over  two  indices  do  not  have 
(c,  s)-bounded  reductions.  We  will  first  show  the  following  generic  result  about  CTL\  X: 

Theorem  6.5.1.  For  each  number  i  there  exists  an  CTL\  X  formula  p,  with  the  following 
properties: 

•  pi  is  satisfiable  (and  has  a  finite  model). 

•  pi  uses  only  two  atomic  propositions  l  and  r. 
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•  Every  Kripke  structure  K  where  pt  is  true  has  at  least  i  states. 


•  (pi  has  the  form  EF<^'- 

The  result  is  true  even  when  the  Kripke  structure  is  required  to  have  a  strongly  con¬ 
nected  transition  relation. 

Remark  15.  This  result  is  closely  related  to  early  results  about  characterizing  Kripke 
structures  up  to  bisimulation  in  [14].  The  results  in  [14]  give  rise  to  the  following  proof 
idea  for  Theorem  6.5.1:  Let  Ku ... ,  Kn  be  all  Kripke  structures  with  2  labels  of  size 
<  i,  and  let  /', .....  /,,  be  CTL\  X  formulas  which  characterize  them  up  to  stuttering 
bisimulation.  Consider  now  the  formula  <pi  :=  Ai<j<n  ~l/j-  By  construction  every  model 
of  pi  must  have  >  i  states.  At  this  point,  however,  the  proof  breaks  down,  because  we 
do  not  know  from  the  construction  if  pi  is  satisfiable  at  all.  The  natural  way  to  show  that 
Pi  has  a  model  would  be  to  prove  that  stuttering  bisimulation  over  a  2-symbol  alphabet 
has  infinite  index.  This  property  however  is  a  corollary  to  Theorem  6.5.1,  and  we  are  not 
aware  of  a  proof  in  the  literature. 

For  properties  involving  only  the  presence  of  the  token ,  a  system  PG,  where  67  = 
(S',  67)  essentially  behaves  like  a  Kripke  structure  with  set  of  states  S  and  transition  relation 
67.  To  see  this,  consider  a  system  PG,  where  P  is  a  trivial  process  which  can  always 
receive  a  token,  and  immediately  send  the  token  to  a  neighbor  process.  Let  L  and  t:i  be 
propositional  formulas  stating  that  the  token  is  with  process  i  and  j  respectively.  Since  the 
processes  do  not  influence  the  path  taken  by  the  token,  the  token  moves  only  according  to 
the  network  graph  67,  and  thus  for  each  path  on  PG  there  exists  a  corresponding  path  in  67. 
Consequently,  if  a  path  on  PG  satisfies  a  property  without  X,  then  the  corresponding  path 
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on  G  also  satisfies  this  property.  Now  we  can  show  by  contradiction  that  indexed  CTL\  X 
cannot  have  bounded  reductions.  Suppose  CTL\X  did  have  (c,  s)-bounded  reduction  for 
some  s.  Then,  by  Theorem  6.5.1,  we  can  always  find  a  CTL\X  formula  <f>  such  that  the 
network  graph  underlying  any  system  that  satisfies  <f>  must  have  size  at  least  c  +  1.  Thus 
CTL\X  does  not  have  bounded  reductions.  Consequently,  we  also  have  the  following 
corollary: 

Corollary  8.  There  exists  a  network  topology  T  for  which  2-indexed  CTL\  X  does  not 
have  cut-offs. 

A  detailed  proof  can  be  found  in  the  last  section  of  this  chapter. 


6.6  Conclusion 

We  have  described  a  systematic  approach  for  reducing  the  verification  of  large  and  pa¬ 
rameterized  systems  to  the  verification  of  a  sequence  of  much  smaller  systems.  We  will 
conclude  this  chapter  with  further  considerations  concerning  the  practical  complexity  of 
model  checking. 

For  simplicity,  let  us  again  consider  the  case  of  2-indexed  properties.  Suppose  the 
processes  P  in  our  network  have  state  space  \Q\.  Then  our  reduction  requires  to  model 
check  up  to  36  network  graphs  with  4  sites,  resulting  in  a  state  space  of  |Q|4  .  Even  this 
model  checking  problem  may  be  too  expensive  in  practice.  By  a  close  analysis  of  our 
proofs,  it  is  however  possible  to  reduce  the  state  space  even  further  to  0(|Q|2). 

It  is  easy  to  show  that  Lemma  6.4.5  will  hold  even  when  the  processes  at  the  hubs 
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are  simple  dummy  processes  containing  two  states  whose  mere  task  is  to  send  and  receive 
the  token  infinitely  often.  Consequently,  the  systems  PG(‘,i)  will  have  state  space  of  size 

22  x  \Q\2. 

The  results  in  this  chapter  on  LTL\X  were  derived  assuming  fairness  condition  on  the 
systems.  We  can  obtain  similar  reductions  by  removing  this  assumption.  Doing  away 
with  fairness  necessitates  the  consideration  of  two  more  path  types  other  than  the  ones 
described  in  Section  6.4.1.  Consequently,  the  topology  graphs  have  more  than  4  sites  and 
also  the  number  of  different  topology  graphs  increases. 


6.7  Proofs  of  Lemmas 

Proposition  4.  For  2  indices,  there  exist  at  most  36  connection  topologies. 

Proof.  By  our  fairness  assumption,  every  connection  topology  must  be  strongly  con¬ 
nected.  This  implies  that  the  following  conditions  must  hold: 

•  At  least  one  of  $_>(*,  j)  or  j)  must  be  true. 

•  At  least  one  of  i)  or  i)  must  be  true. 

This  means  in  the  characteristic  vector  of  connection  topology  the  following  must  hold: 

•  At  least  one  of  the  second  and  third  elements  (corresponding  to  the  connectivity 
properties  discussed  above)  must  be  1.  This  gives  us  three  choices  in  picking  the 
second  and  third  elements  of  the  vector. 
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•  At  least  one  of  the  fifth  and  sixth  elements  must  be  1.  This  again  gives  us  three 
choices  in  picking  the  fifth  and  the  sixth  elements  of  the  vector. 

•  First  and  fourth  elements  can  be  either  0  or  1.  This  gives  us  four  choices  in  picking 
the  first  and  the  fourth  elements  of  the  vector. 

Consequently  the  number  of  different  possible  characteristic  vectors  is  3  x  3  x  4  = 
36.  □ 

Lemma  6.4.5.  Let  G , ,  64  be  network  graphs,  P  a  process,  and  (p(x,y)  a  2 -indexed 
quantifier-free  LTL\X  property.  Let  ai,  b\  be  a  pair  of  indices  on  G \,  and  a2,  b2  a  pair 
of  indices  on  G2.  The  following  are  equivalent: 

(a)  (Gi,  ai,  b\)  ~2  (G2,  a2,  b2),  i.e.,  a±,bi  and  a2,  b2  have  the  same  connectivity. 

(b)  PGl  \=  p(ai,  bf)  iff  P°2  f=  (p(a2,  b2). 

We  first  define  some  notions  which  will  be  helpful  in  proving  the  lemma.  Let  PG  be  a 
system  with  m  processes 

An  execution  trace  of  the  system  PG  is  a  series  of  global  states  in  such  that 
there  is  a  transition  from  every  kth  state  in  the  trace  to  the  (k  +  1  j th  state. 

Given  a  trace  t,  we  will  denote  the  nth  state  in  t  by  t". 

A  witness  in  system  PG  for  a  LTL  \  X  formula  (where  Pi  and  Pj 

are  two  processes  in  G )  is  an  execution  trace  of  S  that  satisfies  the  LT L\  X 
formula. 
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We  now  define  the  projection  of  an  execution  trace  with  respect  to  a  set  of  indices  I  = 

4}.  First  we  describe  the  collapse  of  a  trace  with  respect  to  I. 

Definition  6.7.1.  Given  an  execution  trace  t  of  a  system  PG  and  a  set  of  indices  /,  the 
collapse  of  t  with  respect  to  /  is  obtained  by  removing  every  global  state,  tn+1  in  t  such 
that  Vi  G  I.tn(i)  =  tn+l(i) 

Informally,  a  collapse  of  trace  t  is  obtained  by  removing  those  global  states  from  the 
trace  which  do  not  change  the  states  of  processes  with  indices  I. 

Definition  6.7.2.  Given  a  collapsed  trace  tc  of  PG  with  respect  to  /  the  projection  of  t 
with  respect  to  /  is  the  series  of  states  obtained  by  projecting  each  global  state  in  tc  onto 
the  processes  in  I. 

Lemma  6.7.3.  If  two  execution  traces,  t\  and  t2  have  the  same  projection  with  respect  to 
a  set  of  processes,  I,  then  the  two  traces  satisfy  exactly  the  same  set  ofLT  L  \  X  properties 
over  I. 

Proof  This  follows  from  the  semantics  of  LTL  \  X  properties.  □ 

Lemma  6.7.4.  A  system  PG  with  two  indices  i  and  j  satisfies  an  LT L\ X property  pit,  j ) 
if  and  only  if  the  system  PG(*,n  satisfies  the  property  p(site  i ,  site2). 

Proof.  We  will  prove  that  if  PG  satisifes  a  property  p(i,  j )  then  PG(^j)  satisfies  p(site i ,  site 2). 
The  proof  for  the  other  direction  is  exactly  the  same. 

Consider  any  two-indexed  LTL  \  X  property  p(t,j).  Let  system  PG  satisfy 
Consider  a  witness,  w,  for  ip(i,  j)  in  the  system  S.  Obtain  the  projection,  wp,  of  w  with 
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respect  to  indices  i,j.  Note  that  each  state  in  wp  will  be  of  the  form  (qt.  q3)  where  qt,  qj 
are  local  states  of  processes  i,j  respectively. 

We  will  say  a  trace  w'  of  matches  wp  if  the  projection  of  w'  with  respect  to  in¬ 

dices  site i  and  site2  is  isomorphic  to  wp  modulo  renaming.  Clearly,  if  a  trace  w'  matching 
wp  exists  in  PG(a)  then  the  system  satisfies  the  property  tp(site i,  site2). 

We  will  now  construct  a  trace  w'  of  PGti.i)  that  matches  wp.  The  state  of  process  i  in 
PG  will  be  matched  by  the  state  of  process  site  i  in  PGtcj)  and  the  state  of  process  j  will  be 
matched  by  the  state  of  process  site2.  Consider  the  first  state  (q,.  q3)  of  the  trace  wp.  Since 
(qi,  qj)  is  the  first  state  of  the  trace  wp,  both  q,  .  q:i  must  be  the  initial  local  states.  The  first 
state  of  w'  will  then  be  ( qSite1,qhub1,qsite2,qhub2 )  where  qsitei  ■  qSite2  are  initial  local  states. 
The  hubs  can  be  in  any  local  state,  so  by  default  we  require  them  to  be  in  initial  states  as 
well. 

The  token  could  be  held  in  three  possible  ways  the  state  (qtl  q3 ): 

•  By  process  i. 

•  By  process  j. 

•  By  neither  i  nor  j 

In  case  the  token  is  with  process  i  then  in  w'  the  token  will  be  with  process  site i.  In 
case  the  token  is  with  process  j  then  in  w'  the  token  will  be  with  process  site2.  In  the  last 
case,  the  first  global  state  of  w',  (qsitei,  qhub^  qSite2,  qhub2),  is  such  that  token  is  with  qhubl 
or  qhub2  ■  It  is  easy  to  see  that  the  first  state  of  w'  thus  constructed  matches  the  first  state  of 

wp. 
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Assume  that  we  have  been  able  to  construct  a  prefix  pf  of  w'  which  matches  the  prefix 
of  wp  of  length  k.  Denote  the  mth  state  in  wp  by  w™  and  the  prefix  of  length  m  by  m-prefix. 

To  extend  the  trace  w'  to  k  +  1  states  consider  the  states  wk  and  wk+1  of  wp.  We  have 
the  following  cases  to  consider: 

•  In  going  from  wp  to  wk+1  there  is  no  change  in  the  process  holding  the  token.  As¬ 
sume,  without  loss  of  generality,  that  the  difference  between  wk  and  wk+1  is  a  change 
in  the  local  state  of  process  i.  Consider  w'k ,  the  kth  state  of  w' .  Since  w'  matches 
the  h -prefix  of  wp,  the  states  of  process  i  in  wp  and  process  site i  in  w'k  must  match. 
This  means  whatever  action  i  can  take,  the  same  action  can  be  taken  by  site  Thus, 
we  can  extend  w'  to  k  +  1  states  by  replicating  the  action  of  process  i  using  process 
site i. 

•  In  wk  the  token  is  with  i  and  in  wk+1  is  with  j.  We  can  then  infer  that  there  must  be  a 

P  P  J 

direct  edge  in  G  from  process  i  to  j,  that  is,  G  |=  j)  must  be  true.  Thus  there 
must  be  a  similar  direct  edge  in  G^p  from  site  1  to  site2,  that  is  in  G^j)  h  ‘M*,  i) 
is  true.  And  since  the  prefix  pf  of  w'  matches  the  A-prcfix  of  wp,  in  the  last  state  of 
pf,  w'k,  the  token  must  be  with  process  site i.  Further,  the  states  of  site  i  and  site2 
in  w'k  must  be  the  same  as  the  states  of  i  and  j  (respectively)  in  wk.  Thus,  we  can 
extend  w'  with  the  state  that  is  obtained  by  a  token  transfer  from  site  i  to  site 2.  Thus 
we  have  a  prefix  of  w'  that  matches  the  k  +  1-prefix  of  wp.  The  case  where  token  is 
with  j  in  wp  and  with  i  in  wk+1  is  analogous. 

•  In  wk  the  token  is  with  neither  i  nor  j  and  in  wk+1  it  is  with  j.  This  case  has  the 
following  three  sub-cases 
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In  the  A-prcfix  of  wp  the  token  was  last  with  j.  That  is,  there  is  a  state  w™\ 
m  <  k  such  that  the  token  is  with  process  j  in  w™  and  in  no  state  w™,  m  < 
n  <  k  is  the  token  with  either  process  i  or  j. 

This  implies  that  there  a  path  from  j  to  itself  in  G  that  does  not  go  through  i, 
that  is  G  |=  T.r'; (j,  i).  Then  there  must  be  a  similar  path  from  site 2  to  itself  in 
G(ij)  which  does  not  go  through  site  1,  that  is,  G^j)  \=  ^^(site 2,  site  1)  must 
hold.  Since  pf  matches  A  -prcfix  of  wp,  the  process  that  last  had  the  token  in  pf 
must  be  site 2.  In  the  last  state  l  of  pf  the  token  is  neither  with  site  1  or  site 2. 
We  can  infer  that  the  token  must  be  with  process  hub2  because  site 2  can  send 
token  to  either  site  1  or  hub2  and  the  token  is  not  with  site  1.  Then  we  can  add 
a  series  of  states  to  pf  such  that,  at  the  end,  token  is  transferred  back  to  site2 
and  the  only  process  that  changes  the  state  in  this  series  of  states  prior  to  token 
transfer  is  hub2.  This  is  always  possible  because  of  our  assumption  that  each 
process  can  send  and  receive  token  infinitely  often.  Thus  we  now  have  prefix 
of  w'  that  can  match  the  first  k  +  1  states  of  wp. 

In  the  A;-prefix  of  wp  the  token  was  last  with  i.  This  means  that  there  a  path 
from  i  to  j  in  G  that  goes  through  a  third  process,  that  is  j)  must  hold 
in  G.  Then  there  must  be  a  similar  path  from  site  1  to  site2  in  Guj)  that  goes 
through  hubp  In  the  last  state  l  of  pf  the  token  is  with  h  ulj  1 .  To  see  this,  note 
that  site  1  can  send  token  either  to  hubi  or  site 2  and  in  /  the  token  cannot  be 
with  site 2  (otherwise  pf  will  not  match  the  A;-prefix  of  wp ).  As  before,  we  can 
add  a  series  of  states  to  pf  such  that  at  the  end  token  is  with  site 2  and  the  only 
process  that  changes  state  prior  to  token  transfer  is  process  hub\. 
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-  In  the  A; -prefix  of  wp  the  token  was  never  with  i  or  j.  That  is  w^+1  is  the  first 
state  where  the  token  is  with  j.  We  have  constructed  pf  such  that  it  matches 
the  A; -prefix  of  wp.  Since  there  was  no  token  transitions  involving  either  i  or 
j,  all  the  transitions  in  pf  must  have  been  transitions  local  to  i  or  j.  Thus,  it 
does  not  matter  where  the  token  was  initially  in  pf.  Since  we  are  interested 
only  in  existential  properties,  we  can  construct  pf  such  that  the  token  is  with 
process  hub2  in  the  last  state  l.  This  means  that  from  l  we  can  have  a  token 
transition  from  process  hub-2  to  site 2.  Thus  we  can  extend  pf  so  that  it  matches 
k  +  1-prefix  of  wp. 

The  case  where  the  token  is  with  neither  i  nor  j  in  the  state  uf;'  and  with  i  in  the  state 

o  p 

Wp+1  is  analogous. 

Thus,  we  can  construct  a  trace  of  w'  of  S'  which  matches  wp. 

Note  that  we  have  implicitly  used  the  fairness  assumption  for  PG.  The  assumption  is 
implicit  in  the  fact  there  is  always  a  k  +  1th  state  in  pf  that  is  to  be  matched. 

□ 

Lemma  6.7.5.  Let  PG]  and  PG 2  be  two  systems.  Further  let  there  be  two  processes 
indexed  i  and  j  in  both  G\  and  G-2.  If  for  all  two  indexed  LTL  \  X  property  p(i.  j), 

PGl  h  &  p°2  H  then  G1{i  j)  =  G2(iJ). 

Proof.  The  proof  strategy  is  the  following.  For  each  path-type,  we  will  give  a  two-indexed 
LTL  \  X  formula  ^(i,  j)  such  that  if  'Tfy,  j)  holds  on  a  system  PG  then  the  associated 
path-type  exists  between  i  and  j  in  the  network  G. 
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The  three  formulas  are: 


•  For  <F0(i):  F  (ti  A  (-itj  U  ->(ti  V  tj))  U  U) 

•  For  j):  F  (£*  A  (~>tj  U  ->(ti  V  tj))  U  A,) 

•  For  $_>(*,  j):  F  (L  A  (U  U  tj)) 

It  is  easy  to  see  that  each  of  the  three  formulas  implies  the  associated  path  type. 

Now  if  PGl  satisfies  exactly  those  two-indexed  properties  as  P°2,  then  the  two  systems 
must  satisfy  exactly  the  same  type  formulas.  Hence  G i(.  =  G 2(. j}  □ 

Lemma  6.4.5.  We  first  prove  that  (i)  =>■  ( ii ).  Assume  that  (Gi,a,i,bi)  ~2  (G2,  a2,62). 
Then  we  know  that 

Gi  ,  .  =  G2,  ,  . 

By  Lemma  6.7.5, 

PGl  |=  93(01,61) 

AA  p  Tl(«i.fei)  |=  (pi^site i,  site2) 

-£=>■  pG2(a2,i>2)  [=  sife2) 

FG2  |=  ip(a2,b2 ). 

For  the  other  direction,  assume  PGl  |=  93(01,  6i)  AA  PGs  |=  p(a2,  b2).  Now, 

PGl  |=  93(01,61)  pGl(«i.i>i)  |=  </3(sifei,  site2) 
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and 


P°2  f=  93(02,62)  O  PG2(o 2’62)  |=  (p(sitei,site2)- 


Thus 

PG\a  1,61)  |=  <p(site\,  sitef)  O  PG2(° 2.*>2)  |=  (p(sitei,  site2) 

which  implies,  by  Lemma  6.7.4,  that  Gi(  6  }  =  G2(a2  6  }  and  therefore (Gi,  Gq,  61)  ~2 
(G2,  02,  62). 

□ 

Theorem  6.4.14  For  k-indexed  specifications,  all  network  topologies  T  have  (2k,  3k(k  l>2k)- 
hounded  reductions. 

Proof.  Let  93  be  a  A-indcxcd  specification  and  G\,  G2, . . .  be  an  enumeration  of  the  net¬ 
work  graphs  in  T.  Since  model  checking  for  each  graph  G*  G  T  is  (2k,  3fc^-1)2fc)-bounded 
regardless  of  the  size  of  Gt,  we  obtain  a  sequence  of  Boolean  functions  B,  over  the  same 
variables  gi,  ■  ■  ■ ,  g3nk-i)2k.  Consider  now  the  (infinitary)  conjunction  B  :=  f\i>1  Bi.  By 
Corollary  7,  the  function  B  expresses  that  for  all  G,  we  have  Gf  |=  93.  It  remains  to 
show  that  T  is  equivalent  to  a  finite  formula.  Since  B  depends  only  on  a  finite  number 
(3fc(fc-i)2fc)  of  Boolean  variables,  functional  completeness  of  Boolean  logic  implies  that  B 
is  equivalent  to  a  finite  formula  of  size  at  most  23k(k  1,2\  □ 

Theorem  6.5.1.  For  each  number  i  there  exists  a  CTL\X  formula  with  the 
following  properties: 

•  93,  is  satisfiable  (and  has  a  finite  model). 
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•  (fi  uses  only  two  atomic  propositions  l  and  r. 


•  Every  Kripke  structure  K  where  is  true  has  at  least  i  states. 

•  pi  has  the  form  EF^'. 

The  result  remains  true,  when  the  Kripke  structure  is  required  to  have  a  strongly  con¬ 
nected  transition  relation. 

Proof.  Our  goal  is  to  describe  a  formula  p%  using  atomic  propositions  l  and  r  whose  mod¬ 
els  must  have  at  least  i  states.  We  will  construct  a  large  conjunction  A</>er  and  describe 
which  formulas  to  put  in  T.  The  idea  is  simple:  T  needs  to  contain  i  CTL\X  formulas 
which  describe  the  existence  of  i  different  states.  Then  the  formula  EF  /\,.Gr  A  will  be  the 
sought  for  pi. 

Consider  a  Kripke  structure  K  as  in  Figure  6.5: 

•  In  Level  0,  it  contains  two  distinct  states  L,  R  labelled  with  l  and  r  respectively.  To 
express  the  presence  of  these  states,  we  include  the  formulas,  let  Lq  :=  (/  A  ->r)  and 

:=  (r  A  -i /),  and  include  EF^1  and  EF^o  into  T. 

It  is  clear  that  EFA’d  and  EFr'o  express  the  presence  of  two  mutually  exclusive 
states. 

•  In  Level  1,  K  contains  22  —  1  =  3  states,  such  that  the  first  one  has  {L,R}- free 
paths  to  L  and  R.  the  second  one  an  { L .  Ii }  -free  path  only  to  L,  and  the  third  one 
an  {L,  /?}-frec  path  only  to  Ii.  The  characteristic  properties  of  level  1  states  are 
expressed  by  formulas 
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Figure  6.5:  The  Kripke  structure  K,  constructed  for  three  levels.  The  dashed  lines  indicate  the  connections 
necessary  to  achieve  a  strongly  connected  graph. 

ij}\  :=  EF^o  A  EF 
V’?  :=  EF^V’o  A  -EF 
'll)' l  :=  -EF^V’o  A  EF 

where  EF'a;  denotes  E(=/  A  ->r)U.x,  i.e.,  a  variant  of  EF  which  forbids  paths 
through  L  and  R.  To  enforce  the  existence  of  the  Level  1  states  in  the  Kripke  struc¬ 
ture,  we  include  EF^,  EF ip\,  ~EFipf  into  T. 


•  In  Level  2,  K  contains  23  —  1  =  7  states,  such  that  every  state  in  level  2  can  reach 
one  of  the  7  non-empty  subsets  of  Level  1 .  The  characteristic  properties  of  Level  2 
states  can  be  expressed  by  formulas  such  as 

till  :=  EF -tj}\  A  EF A  EF~^3 
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and 

:=  ^EF^1  A  EF"^2  A  EF"^? 

,  etc  including  to  uf.  To  enforce  the  presence  of  Level  2  states  in  the  Kripke 
structure,  we  include  the  formulas  EF^  for  i  —  1, ...  ,7  into  T. 

•  In  general,  each  Level  k  has  at  least  2k+1  —  1  states  that  differ  in  their  relationship 
to  the  states  in  Level  k  —  1.  The  presence  of  such  states  is  expressed  by  formulas 

EF-0fe. 

All  these  formulas  are  included  into  T  until  the  requested  number  i  of  different  states  is 
reached.  By  construction,  all  properties  required  by  the  theorem  are  trivially  fulfilled.  In 
particular,  Figure  6.5  demonstrates  that  there  always  exists  a  strongly  connected  model. 

□ 

The  formula  uses  two  labels  l,  r.  To  use  the  above  theorem  in  the  setting  of  systems 
with  network  graphs,  we  replace  the  labels  /,  r  by  atomic  propositions  tx.  ty.  Recall  that  an 
atomic  proposition  tx  states  that  the  token  is  with  process  x.  We  will  denote  the  modified 
formula  by  (pfx,y).  We  have  the  following  proposition  as  a  consequence  of  the  above 
theorem. 

Corollary  9.  If  PG  |=  3x,  y.  tfi(x,  y ),  where  G  =  (S,  C)  then  \S\  >  i. 

Proof.  Consider  formula  3 x,y.ipi(x,y)  and  suppose,  towards  a  contradiction,  that  there 
is  a  system  PG,  G  =  ( S,C )  where  \S\  <  i  such  that  PG  |=  3 x,y.ipi(x,y).  Then  there 
exist  indices  a,  b  such  that  PG  |=  tpfa,  b ).  We  construct  the  Kripke  structure  /C  with  state 
space  S,  transition  relation  C,  initial  state  1,  and  two  atomic  propositions  ta,  h  which  hold 
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true  on  states  a  and  b  respectively.  Note  that  since  the  formula  c pi(a,b )  is  of  the  form 
EF(/3-(a,  b)  and  C  is  strongly  connected,  satisfaction  of  pfa,  b)  does  not  depend  on  the 
choice  of  the  initial  state.  Since  we  know  that  for  all  paths  on  PG,  the  corresponding  paths 
on  G  preserve  properties  without  X,  it  follows  that  /C  |=  pfa,  b).  By  the  above  theorem, 
/C  must  have  at  least  i  states,  which  contradicts  our  assumption  that  \S\  <  i.  Thus,  we 
have  a  proof  by  contradiction  that  if  PG  (=  3x,  y.ipfx,  y )  then  the  network  graph  G  must 
have  at  least  i  nodes  in  it.  □ 

Corollary  8.  There  exists  a  network  topology  T  for  which  2- indexed  CTL  \  X 
does  not  have  cut-offs. 

Proof.  Let  T  be  the  class  of  strongly  connected  graphs.  Then  Corollary  9  tells  us  that 
3x,  y.(pn(x,  y)  does  not  have  a  cut-off  for  T.  □ 


6.8  Connection  Topologies  for  2-Indices 


All  the  36  possible  connection  topologies  between  two  processes  are  presented  below. 
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Chapter  7 


Conclusion 


7.1  Summary 


This  thesis  presents  an  efficient  abstraction  technique  to  facilitate  model  checking  of 
parameterized  systems  with  replicated  processes.  All  successful  applications  of  model 
checking  thus  far  have  made  use  of  domain  specific  abstraction  techniques.  Continuing 
this  trend,  we  exploit  the  domain  knowledge  about  parameterized  systems  to  devise  an 
appropriate  abstraction  method. 

The  problem  of  verifying  parameterized  systems  is  both  challenging  theoretically  (be¬ 
cause  of  their  unboundedness)  and  very  relevant  practically  (because  many  crucial  com¬ 
ponents  of  real  systems  are  parameterized).  For  example,  in  the  recent  years,  verification 
of  cache  coherence  protocols  has  become  a  very  important  problem  in  the  hardware  indus¬ 
try.  All  the  modem  multi-core  architectures  have  very  intricate  cache  coherence  protocols, 
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and  there  are  no  rigorous  techniques  for  their  verification.  Similarly,  the  number  of  con¬ 
trollers  used  in  embedded  applications,  for  example  on  automobiles,  is  also  increasing, 
and,  to  facilitate  efficient  communication  between  the  controllers,  complex  time  triggered 
protocols  are  being  developed.  These  protocols  are  also  parameterized  as  the  number  of 
controllers  can  vary.  As  with  cache  coherence  protocols,  there  are  no  efficient  automated 
techniques  for  verifying  these  protocols.  To  model  check  complex  protocols  like  these,  we 
need  efficient  abstraction  techniques. 

In  this  thesis,  we  present  an  abstraction  method  called  environment  abstraction  for 
verifying  parameterized  systems  with  replicated  processes.  The  main  insight  in  this  tech¬ 
nique  is  that,  when  a  human  designer  reasons  about  a  system  with  replicated  components, 
(s)he  tends  to  focus  on  a  reference  component  and  consider  the  environment  around  it. 
We  formalize  this  insight  and  provide  a  rigorous  framework  for  constructing  such  abstract 
models.  The  abstract  models  are  quite  precise  and  easy  to  construct.  In  most  abstraction 
methods,  liveness  properties  are  more  difficult  to  handle,  even  theoretically,  than  safety 
properties.  Our  method,  however,  has  a  simple  extension  to  handle  liveness  properties. 
Finally,  most  automatic  abstraction  based  methods  for  verifying  parameterized  systems 
use  the  atomicity  assumption.  In  contrast,  we  are  able  to  remove  the  atomicity  assumption 
by  adding  monitor  processes  and,  thus,  verify  protocols  in  their  full  generality.  Our  ex¬ 
periments  with  different  cache  and  mutual  exclusion  protocols  suggest  that  environment 
abstraction  works  extremely  well  in  practice. 

The  insight  of  constructing  an  abstract  model  by  considering  one  reference  process 
and  looking  at  the  world  around  it  can  be  generalized  to  different  settings.  Instead  of  just 
considering  a  collection  of  processes,  each  of  which  can  talk  with  every  other  process, 
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we  consider  a  richer  model  in  which  processes  are  arranged  on  the  nodes  of  a  network 
graph.  Thus,  in  addition  to  replication  of  processes,  we  also  have  an  arbitrary  network 
graph  to  reason  about.  This  problem  structure  is  quite  common  in  real  life.  For  instance, 
network  routing  protocols,  which  route  data  through  complicated  networks  of  machines, 
have  to  function  no  matter  what  the  structure  of  the  network.  Each  of  these  machines  runs 
the  exact  same  routing  protocol.  While  there  has  been  work  on  verifying  systems  with 
replicated  processes,  there  has  not  been  much  work  on  verifying  systems  with  network 
graphs.  In  Chapter  6,  we  take  the  first  steps  towards  verifying  parameterized  systems 
with  network  graphs.  We  consider  the  verification  of  two  process  properties  and  show 
how  to  decompose  a  system  with  a  large  network  to  a  collection  of  systems  with  constant 
sized  network  graphs.  The  main  idea  is  that  it  suffices  to  consider  how  the  network  looks 
from  a  pair  of  processes  to  figure  out  what  properties  the  pair  satisfies.  It  can  also  be 
shown  that,  for  any  pair  of  processes,  there  are  only  a  finite  number  of  possibilities  for 
how  the  network  around  them  can  look  like.  The  results  presented  in  Chapter  6  also 
highlight  an  interesting  contrast  in  the  expressive  power  of  LTL  and  CTL  specifications. 
We  show  that,  while  decomposition  of  large  network  into  smaller  ones  is  possible  for 
LTL  specifications,  it  is  not  possible  for  CTL  specifications.  Informally,  two  process  CTL 
specifications  can  encode  information  about  the  number  of  other  processes  in  the  system 
and,  thus,  decomposition  is  not  possible  for  CTL  properties. 
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7.2  Extensions 


In  this  thesis,  we  considered  parameterized  systems  with  replicated  processes.  Environ¬ 
ment  abstraction  is  quite  general  and  can  be  applied  even  when  the  replicated  components 
are  not  processes  or  if  there  are  multiple  types  of  replication.  For  instance,  we  can  think 
of  a  memory  bank  as  a  collection  of  identical  components  (ignoring  the  contents  of  the 
memory).  Similarly,  we  can  treat  a  collection  of  jobs  waiting  to  be  scheduled  in  a  queue 
as  an  instance  of  replication  (ignoring  the  specifics  of  the  job).  We  believe  this  viewpoint 
will  lead  to  useful  abstractions. 

The  abstract  model  that  we  construct  is  doubly  exponential  in  the  number  of  local  state 
variables.  In  real  cache  coherence  protocols,  the  internal  state  of  each  cache  can  be  quite 
complex  and  thus  our  method  might  fail.  To  get  around  this,  the  internal  states  of  local 
caches  themselves  might  have  to  be  abstracted  before  applying  environment  abstraction. 
An  interesting  extension  to  our  work  would  be  to  combine  environment  abstraction  with 
standard  abstraction  for  the  internal  states  of  the  caches. 

Our  work  in  Chapter  6  lays  the  foundational  results  for  the  verification  of  parame¬ 
terized  systems  with  network  graphs.  While  the  system  model  does  consider  a  network 
graph,  the  communication  between  the  processes  is  very  simple.  An  extension  to  our  work 
would  be  to  consider  richer  communication  between  processes.  However,  we  suspect  that 
the  decomposition  results  may  not  exist  even  for  LTL  properties  once  we  allow  more  than 
one  token.  It  would  be  interesting  to  consider  what  restrictions  to  impose  on  the  system 
model  so  that  we  can  still  obtain  decomposition  results. 

The  abstraction  based  approach  we  have  presented  for  verification  of  parameterized 
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systems  is  just  one  possible  approach.  In  most  real  world  parameterized  systems,  it  seems 
to  be  the  case  that,  all  possible  two  process  behaviors  are  exhausted  when  the  parameter 
value  is  just  4  or  5.  If  such  a  cutoff  really  exists,  then  parameterized  verification  is  no 
different  from  ordinary  verification.  But,  finding  such  cutoffs  is  very  hard  and  no  such 
cutoffs  are  currently  known.  A  related  idea  is  to  determine  cutoff  on  trace  length:  it  would 
be  extremely  useful  in  practice  if  we  can  show  that  all  interesting  behaviors  are  exhibited 
by  traces  of  length  less  than  a  certain  cutoff  c.  For  instance,  we  could  use  bounded  model 
checkers,  which  are  typically  faster  than  the  other  types  of  model  checkers,  to  explore  the 
parameterized  system  up  to  depth  c.  If  no  bug  is  found,  then  our  cutoff  result  ensures  that 
the  parameterized  system  is  correct.  While  it  seems  such  trace  cutoffs  must  exist,  no  one 
has  succeeded  in  finding  them  yet.  Finding  cutoff  results  is  a  challenging  problem  with 
significant  practical  impact. 

Distributed  and  parallel  systems  are  among  the  hardest  systems  for  humans  to  rea¬ 
son  about.  Yet  parallelism  seems  to  afford  the  easiest  route  to  scalability  and  increased 
performance.  Consequently,  highly  parallel,  distributed  computer  systems  are  becoming 
quite  pervasive.  Powerful  verification  techniques  are  required  to  ensure  the  correct  func¬ 
tioning  of  these  systems.  Model  checking,  which  performs  an  exhaustive  search  of  the 
state  space,  seems  ideally  suited  for  verification  of  distributed  systems.  In  this  thesis,  we 
have  addressed  the  problem  of  model  checking  distributed  protocols  like  cache  coherence 
protocols  and  mutual  exclusion  and  demonstrated  that  it  is  possible  to  efficiently  and  au¬ 
tomatically  model  check  such  protocols  in  their  full  generality. 
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